|
Hi, I have an application written in c# UWP running on a Windows 10 tablet. It uses ultralite for the remote database. SQL Anywhere V17.0.4.2053. Randomly, I am getting the -208 ultralite error 'Row has changed since last read -- operation canceled' so the record is not updated. The software inserts this record and then updates it along the way through the process. I need advice on what could cause the problem and how to prevent it from happening. Maybe some helpful info...the software creates a single connection object and uses it throughout the operation. Also, after every completed process, it replicates the data in a background operation using the same connection object. Thank you, Paula Edited to correct - I was mistaken. The background replication does not use the same connection object. |
|
Background process should be using a different connection than the foreground. Connections should not be shared between threads. I was mistaken. The background replication uses a different connection object. Also, the background replication only uploads records - no records in the remote are updated by the replication.
(17 Apr '20, 09:31)
Paula
|
|
Hi Paula, The easiest way to cause this error is as follows: Position a cursor (or table object) on row A. Update or delete row A using another cursor or statement. Perform a positioned update or delete on the original cursor -- it's still on the original row A and fails with -208. In fact, a repeated positioned delete on a cursor/table without a fetch/move call will cause this error. This should be straightforward for you to confirm. To handle this in your app, I think the first step is to be clear about what code and sequence and cursors update these rows. Then, if necessary, cursors may need to be repositioned/refreshed at certain points. Positioned updates are very convenient and efficient but they sometimes add complexity. An alternative that works for some applications is to execute the modifications as separate statements rather than cursor-positioned. But hopefully you don't have to go that far :-)
(21 Apr '20, 13:28)
Tim McClements
Thank you for the information. I thought it was something like that. My code actually doesn't do any positioned updates. When I select from the table, I read the result set immediately and store the info elsewhere. Once I have all the data I need, I close the result set. I run direct SQL for all inserts and updates. I think I have a bug where a result set is not being closed. Could that cause this error? If it could, is there a way to tell if there's an open result set?
(22 Apr '20, 11:34)
Paula
Replies hidden
In that case we need to know more about when exactly the error occurs :-) What statement has the error and what else is going on at the time? I don't think leaving a result set/cursor open itself would cause this error.
(22 Apr '20, 12:39)
Tim McClements
I'll try to get that info but since it happens randomly (enough to be a pain) I don't have a lot of control. Do you have any suggestions about what I can do when I get the error? I can check for a 208 and maybe re-run the update statement? Do you think that's a good idea?
(22 Apr '20, 14:29)
Paula
Replies hidden
I can't comment on a solution until we know more about what's happening... Do you log or report the errors in the app somehow? Can you easily include the statement with the error? Maybe also log when synchronization starts and stops?
(22 Apr '20, 16:28)
Tim McClements
|
