Thanks Mark - yes, re-setting the FetchSize property to -1 as you suggest, does seem to prevent the timing out. However it still leaves my main issue:

> HERE is the problem: TABLEUPDATE(1,.T.) returns .T. indicating that
> "changes to all records are committed". However, upon checking the
> table in SQL Query Analyzer, some or all of the data has NOT been committed!!!
>

This seems like such an obvious bug, I cannot imagine why there are no UT threads dealing with it... no mention in the Hacker's Guide, any other book or resource. Nothing.

Also disturbing is the very inconsistent behavior... I'll cycle through a few COMMIT's to this RV using TableUpdate() and everything works fine. Then here comes another false transaction, returning .T. when obviously the rows have NOT been committed at all.

Even more! I can tweak CursorSetProp('BatchUpdateCount', 100, 'VIEW'), which is supposed to "greatly increase update performance" according to Help.

In fact, adjusting this value now causes TableUpdate() to update ONE row at a time!! Instead of ALL rows, as the RV is set for Table Buffering.