> Upon accessing this view, I issue and FLOCK('MYVIEW') to lock the table.

Are you sure that this statement is doing what you expect it to do?

Given how remote views work, for the most part FLOCK() on a view will not actually do a proper table lock on the remote view - and likewise the UNLOCK
has no corresponding effect.

VFP does not actually allow you to take a physical lock on server data -
this is a SQL issue for the most part.

The whole point of optimistic buffering is that any locking is only done
during the commit process - ie the save


> This bogus table is also used in another application(Powerbuilder). After my update, I issue an UNLOCK IN MYVIEW. Apparently, I'm not doing something right because my app tends to lock the other application up when they try to access this table.

At a guess, this is probably a side effect of the ODBC pipe being used to
access your SQL server. It is possible the FLOCK() is somehow locking this
pipe and not releasing it.

The best solution is to fet rid of the FLOCK() calls and UNLOCK calls, and handle the update using tableupdate() with optimitic update error logic.
Basically, if the update fails - start again.