Indeed, SQLAnywhere no longer depends on DYLD_LIBRARY_PATH.

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?

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.

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

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 ori...