John (and also Bob Archer who I referred to this post),

Here are more details and the pertinent code.

First: SQL 7, VFP 6 SP3, Win 98 client.

SQLConnection works fine - conn handle is stored in prop of my dataobject.
My SQLExec is wrapped in a method of that same object - I am having no communication/connection issues here.

The data iteself is returned via a SQL Server Stored Proc to which I orignally pass a "where clause". the SP use dynamic SQL and returns a result set including my integer, surrogate key field which we'll call 'keyfield' for now. On the server, this keyfield is set up as an identity field.

In my scenario - I am initially doing a "nodata" pull of the table via the SET FMTONLY ON (and then OFF after retrieval) syntax. So I start with an "empty" cursor.

Once I get the cursor - I do basically the following:

CURSORSETPROP("tables", ."correct name of back end table")
CURSORSETPROP("updatenamelist", "correct list is here - basically all fields in cursor")
CURSORSETPROP("keyfieldlist", "keyfield")
CURSORSETPROP("updatablefieldlist", "again , all fields are here - minus 'keyfield' of course")
CURSORSETPROP("sendupdates", .T.)
CURSORSETPROP("updatetype", 1)
CURSORSETPROP("wheretype", 1)
CURSORSETPROP("batchupdatecount", 20)
CURSORSETPROP("fetchsize", 200)
CURSORSETPROP("buffering", 5, "mycursor")

(In real life - most of the parameters or lsits above are stored in my dataobject props or concatenated on the fly - but they seem to be all correct)

AGAIN - I would emphasize that all works perfectly (updates, deletes) if I pull existing records and modify. This would seem to be strong evidence that all is set up correctly.

Back to the subject at hand.
If I APPEND BLANK in mycursor - the key field "defaults" to 0 (zero). I then filll in the fields and issue a tableupdate(.t., .f.) (this is actually wrapped with error handling of course). At this point - it works as expected - data is written to SQL - record on back end correctly has next identity number in keyfield, and I can return that number correctly with an SPT "select @@identity"

Now - lets say I next replace some field in the cursor and try to tableupdate again - I get an "update conflict" and profiler shows clearly why - the update where clause is "where keyfield = 0" which obviously doesn't match up. Now - if I replace the keyfield in mycursor with the correct @@identity value, and try to issue tableupdate - I still get an "update conflict" and per profiler - for the same reason - the "where kyfield = 0" is still being sent.

I've tried Bob's idea of "go recno()" but that doesn't seem to work for me. I've also tried "Refresh()" to no avail.

thanks - I hope this is enough info to help you help me. Let me know if you need more.

Ken







>Ken..
>
>I meant to ask for this before.. why don't you post the code in which you do the sqlconnect and sqlexec, and set the necessary cursor properties. That way, I can get a better handle, no pun intended, on where you problem is...