Hi,

As a followup to my previous thread on @@Identity and Surrogate Keys - I have narrowed down one remaining issue and am now at the point where I want to call this behavior either a "bug" or something I clearly do not understand. I would like someone, if possible, to please confirm theis and explain why it works this way if it is indeed "designed behavior".

In a SPT Updatable cursor - I find that if I set CURSORSETPROP("BatchUpdatecount", 20) - then issuing a TABLEUPDATE(.F., .F.) does NOT update the row in question to the Back-end though it does "update" the cursor in that it sets its GetFLdState(-1) values to 11111 .... across the board.

If I leave "BatchupdateCount" at its default value of 1, then TABLEUPDATE(.F., .F.) works as documented. I have not tried values between 1 and 20.

So - is this the way it is supposed to work? If So - Why? Maybe I'm not understanding what Batchupdatecount is doing exactly. I just set it higher becausethe docs say "Adjusting this value can greatly increase update performance." and that seemed like a good thing to do.


Other than this - I have solved the issue I had with @@identity and will now jump on the side that says identity fields and SPT cursors created from SQL Stored Procs are a) easy and b) stable and c) definitley the way to go IMHO. My data-class wrappers around it make it work like a charm and I have great control as opposed to Remote Views - plus - LOOK MOM! - NO DBC!!!!

Thanks!
Ken