FYI: NOUPDATE and file locking

[jabhawk]

I ran across this in a recent project I created. I had a form that opened tables within the INIT for update as SHARED.

I added a new lookup table and used NOUPDATE to prevent inadvertant updates. But I left off the SHARED qualifier as I thought that it was assumed.

Long story short... NOUPDATE does not affect the file locking only the write back ability. Always specify the SHARED or EXCL qualifiers and save yourself unwanted debugging.

JB


Jonthan A Black

 

[Mike Gagnon]

jabhawk

Or set the table to readonly in the Dataenvironment of the form.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[jabhawk]

Ahh....
That says that you are using a DE. In this case the files are directly opened via a USE in the INIT as their physical name was variable and was using an alias.
JB


Jonthan A Black

 

[dbMark]

Yes, it is good habit to always declare how you open the table, whether EXCLUSIVE or SHARED, and also whether NOUPDATE. Yes, there are exceptions where you want the current environment manipulated by SET EXCLUSIVE ON/OFF to be the determining factor, but generally it's good not too assume too much about the default or current environment.

Another not-so-obvious behavior to keep in mind is that the FoxPro EXCLUSIVE setting applies at the user level, not table level.

Therefore, you can use a table multiple times in different workareas using AGAIN even though you have SET EXCLUSIVE ON.

If you have SET EXCLUSIVE ON then you cannot append from a table in use by another user, again because there is user-level detection.

(I happen to know that dBase 5 for DOS uses table-level detection so its behavior is different.)