|
How do I deal with the situation where a COMMIT raises the following exception? SQLCODE = -660 "SQLE_OMNI_REMOTE_ERROR" SQLSTATE = WO005 ERRORMSG() = Server 'p003': [Sybase][ODBC Driver][SQL Anywhere]Database server not found Presumably, something has gone wrong with a connection to a remote server, but that's not the problem... In this case, there were no outstanding updates on the remote server, but there WERE outstanding updates on the local database and that's what the COMMIT was intended for. (sadly, I don't know whether the local updates were lost or committed) How do I prevent a problem with a remote server from adversely affecting a transaction on the local database? Is there some way to execute a local COMMIT that ignores any connections to remote servers? If it can't be prevented, how should it be dealt with? Is there some way to code an EXCEPTION handler that successfully re-issues the COMMIT? (assume the remote server connection is no longer important) Does the automatic commit associated with ALTER SERVER CONNECTION CLOSE come before or after the remote connection is closed? |
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 16 Sep '12, 09:35
question was seen: 2,638 times
last updated: 17 Sep '12, 03:18
In case the remote access is not really necessary (i.e. , as you state, you would just go on locally), I would wrap all statements related to remote data with exception handlers and catch any errors...
No, that does not answer your questions, it's just a comment:)
That is exactly the case now: The COMMIT is wrapped in its own BEGIN...EXCEPTION block. The question remains, what the [redacted] can the exception handler do about the problem?
Some guesses: As SQL Anywhere uses a T2C protocoll to handle remote data access, I can't image that ALTER SERVER CONNECTION CLOSE could solve the problem during the transaction: Obviously, the final COMMIT must be committed by the remote server, too, and that seems not possible when the remote connection is already closed. It also would mean that when the remote server is not accessible, the COMMIT MUST FAIL.
The following doc tells that savepoints are not supported remotely, so savepoints (aka nested transactions) won't help either to undo/ignore just the remote work...
If these assumptions are correct, I think there are only two workarounds:
(No, not been there, lucky me:)