Hi Erik,

>My concern is with table buffering - there's no way to guarantee that every >modified record is going to make it.
THe view is always buffered, but the table needs no buffering. It is the intention to make changes visisble ASAP and your design decision to always use views (including local views) creates a bit of work. For this purpose I wouldn't use a view/buffered table, just a "normal" table. Personal preference.

>So far, the only way I've seen that works 100% is to pull the table name >out fo the view with a DBGETPROP() and issue a USE IN SELECT(cTableName) on >the line before the TableUpdate(.T.,.F.) - Since views take care of opening >their underlying data source, the TableUpdate will open a fresh updated >copy of the file and compare fields against the fresh copy.
This would be my alst resort, since it is the slowest version by far. I'ld go for the locking scheme until an error manifests there which can be fixed only by closing the table. A simple stepwise approach in the 100 treis should be enough: if the tableupdate fails with the faster methods, use the sledgehammer of closing the table. Shouldn't take too many lines, but be better for overall performance.

regards

thomas