On Apr 30, 9: On Tuesday, May 01, 9: Error Row cannot be located for updating. Some values may have been changed since it was last read fiefie. Are you allowing the value of Order to be updated? If so, it's not really a good candidate for the table's primary key Selstar is not a good programming practice. You should make a point of explicitly naming the columns in your select clause so that 1 you only retrieve the data you need, and 2 you don't force ADO to generate metadata, which sometimes requires an extra trip to the database???
The chapter I provided a link to It should appear on a single line. If your newsreader is breaking the line, you will need to reassemble the link: That would be my preference, except that you must have had some reason to choose an expensive keyset cursor Recordsets, while inefficient for updating data, do provide good functionality for handling concurrency issues. These issues are ones you would need to handle yourself if you resorted to a stored procedure. That chapter I linked to also covers this topic.
Have you tried this to verify that it would work? I think you should run SQL Profiler to get a trace showing the sql statement that generated the error. NET Please reply to the newsgroup. The email account listed in my From header is my spam trap, so I don't check it very often.
You will get a quicker response by posting to the newsgroup. On Tuesday, May 01, 2: Some values may have been changed since it was last read Thank you. I have changed the query to explicitly naming the columns in the select clause. Shall I use server side cursor on the connection? Please let me know if I understand it correctly. Update method somebody else already update either Status,Price,or Location column. Do I understand it correctly?
If I understand it correctly, does it mean that I can trap this error and then resubmit the same query and then do update again? Say the previous value are the following: I am not clear how I should handle concurrency issues if I call a stored procedure to do the update. Thanks a lot for your help. Some values may have been changed since it was last read fniles wrote: Oh, but you were requesting a keyset cursor. With aduseClient, the only cursor type you will get is static adOpenStatic Your decision as to cursor type depends on your need for functionality.
It is really up to you which type you need since i don't know the requirements of your application. In general, if you are opening a cursor, making immediate modifications and closing the cursor, you might as well use either a server or client-side static cursor, or use SQL DML preferably in a stored procedure to make the changes.
That could be the case Read the chapter - Dave Sceppa goes into detail how to handle concurrency issues It could, depending on the settings that Dave talks about. There is a setting to tell ADO to use the primary key only. No, I mean you need to keep track of the state of the field values when they were originally retrieved and before performing the update, compare them to the current field values to see if they've changed in the meantime.
On Tuesday, May 01, 6: Some values may have been changed since it was last read Are you referring to the connection cursor location?
I open the recordset just to change several column values and nothing else , then I do the. If I open the connection using adUseClient, can I just for this recordset use server side cursor?