First of all I don't think you can make definite conclusions after one day of changes. Even though, congratulations on getting use to instantaneous on that table, but, well, you could just have been lucky. Ine thing is okay though, we have discussed and confirmed that, keeping tables open means more often you have the situation 2 or more clients use a file and none of them has an oplock.
But once more: oplocks themselves don't take time, breaking oplocks takes time. And you never can avoid getting an oplock. One user will always be the one that uses a file. And if you change your way, start your app in anticipation of the 20 second wait in a celebration like a new shop opening as the first user of the day, you don't have a 20 second wait. Because you're not the one that has the problem, then.
It's the second user, not the second at that day, the one who gets the second file handle on the file. If the first user of a dbf close the dbf before a second user uses it that also has no problem. As you had this problem regularly, though, the situation of a second user must be quite often. Now you will still always have a second user and that will have a long USE time. unless the first use was so recent, that breaking the opßlock isn't much effort.
And what is breaking an oplock, what has VFP to do with that? Well, nothing. The VFP runtime was as is, before that mechanism was introduced or changed to the bad behavior for VFP and also Access and other software. As oplocks are not real locks, a second user never gets rejected access, a second user demanding shared use of a file gets that, but before he gets that the OS breaks the oplock, and the first client also isn't asked whether he likes that or not, the system does that, but whatever goes wrong on the level of OS clients now asked to flush their cache, maybe VFP is involved with its caching mechanism here. It shouldn't, as VFP has no idea it had an oplock, you can't detect that you have one and VFP does only act on files differently when it knows it has real exclusive access.
So, I don't know, I'd always expect someone to have once a long USE, that's only never happening when there never is the concurrent use of a file. But what's better in going through this phase of one user getting this "penalty" is that when now a third or fourth open the file and the number of handles never goes back to 1, no oplocks will be given anymore.
There is one much simpler solution, though, and that is to prevent them from happening at all. Did you even look at the link I gave I think 3 times already?
Now, regarding your changes: USE database!longtablename will finally also use the same file, workarea and alias name have no influence whatsoever on oplocks. And the only thing that changes is that you look at the DBC once more. But there is another reason this actually make almost no difference for DBFs of a DBC: If you open a DBF by its file name without reference like database!longtablename, you still also open the DBC or verify the consistency of the backlink of a DBF to its DBC stored in its header. Did you ever notice? If you close all tables and databases and just use a DBF of a DBC you also have the DBCopened automatically? So you have a flurry of side actions there anyway, no matter how you do it.
Once a DBC, you have a high chance it's completely read into memory, as a DBC isn't very large, unless you add a lot of stored procs into it. Then this flurry of side actions also becomes inexpensive. Plus all users use the DBC file and will surely only rarely close it.
So, all in all, I only expect 1 to make a difference. And it also only plays a role if despite all settings to turn them off, oplocks still are made.
Again 2008 Server has a solution for that, so you can then also spare changes, almost. I think there is another good aspect of rather long term use of files, I never had good experiences with the tidyness of closing everything you can right away again, you always need to build up from scratch again.
Regarding saving into the dbf file. In buffering you can see the dbf stored value with curval(), from any client, whether you have buffered changes yourself or not, this is also a chance to even predict you get write conflict when your buffered value differs from both curval() and oldval() and so tableupdate wants to change the DBF, but detects that while you changed something from oldval to your workarea value curval() also changed. That's not a technical problem, but the way conflicts are meant is, look, pay attention, someone else already changed the value differently than you wan to. You can always choose the force option and disregard that, making the last change win.
Effectively you have that situation without using buffering. all changes go to the dbf, so whoever saves last saves his change.
Bye, Olaf.
Olaf Doschke Software Engineering
![[rofl2]](/data/assets/smilies/rofl2.gif "[rofl2] [rofl2]")
