My C/S app is a kind of 'data-mart' where VFP parses lots of text files, sending the Inserts/ Updates to SQL Server 7. This backend is primarily used for read-only access; not much editing once it's in there.

I setup a middle-tier oData manager object, with various methods to handle business rules, including a oData.Commit() to the SQL backend. Since I am processing fairly straightforward Inserts/ Updates, I decided to use parameterized VFP Remote Views. Dedicated RV per table, no complex joins or multi-table updates.

Before going further, I have read the debates over RV's versus SPT. Entertaining and informative!<s> OK- there are advantages to SPT. I've got quite a bit invested already into using RV's, without unlimited time to spend re-designing what should work in the first place.

The problem I am having, an apparent bug in TableUpdate() on a parameterized RV which uses Table Buffering. Other RV's using Row Buffering work just fine.

MULTILOCKS is ON.
CursorSetProp('Buffering',"VIEW1") is Optimistic Table Buffering (5).

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!!!

Returning to my RV in VFP, GetNextModified(0) returns zero, confirming what TableUpdate(1,.T.) incorrectly says is committed. GoTo the row where I REPLACE'd a few fields. GetFldState(-1) returns all 1's... indicating "Fields have not been edited". Comparing either CURVAL(fieldX) or OLDVAL(fieldX) to the edited FieldX, shows no difference.

NOW... I am left with uncommitted changes in my RV. However, VFP is telling me the opposite. I have *no way of knowing which fields* have or have NOT been committed! Worse still, since TableUpdate() does not work properly, I can now REQUERY() my RV... meaning that all the edit's I just made are lost. Gone. Vanished!

A clue that it's something in my connection that is causing the problem. I discovered that the connection was timing-out periodically, VFP error 1541- Connection "name" is busy. Note this is not an ODBC error 1526, it's VFP.
I setup the following to test/ debug/ trap it:

FOR i =1 TO 10
* try connection ten times? Never hangs more than once...
*
IF SQLGetProp(CursorGetProp("ConnectHandle", tcAlias), "ConnectBusy")
*
* connection is busy
WAIT WINDOW "Connect TIME OUT "+ ALLT(STR(i)) +" ....." TIME i
IF i= 10
* this has never happened...
lnReturn = -2
ENDIF
ELSE
* connection not busy
lnReturn = IIF(TableUpdate(1, .T., tcAlias), 1, -1)
*
* return the value
EXIT
ENDIF
ENDFOR

NOTE: the false .T. from TableUpdate() only seems to happen after I get one "ConnectBusy". The loop never seems to repeat more than once, IOW the connection only hangs momentarily. The WAIT WINDOW only fires occasionally, so the problem is intermittent... inconsistent, and frustrating! Before I bite the bullet and re-design for SPT - anyone have an idea?

How can this possibly be a "feature" of TableUpdate(), or RV's...