on 2010 Sep 28 12:04 PM
Please confirm: If a SQL Anywhere web service launched from a web browser has called a stored procedure which is executing a SQL statement when the end user gets impatient and presses browser refresh, the SQL statement will be terminated with the following exception:
SQLCODE = -299, SQLSTATE = 57014, ERRORMSG() = Statement interrupted by user
The Help says "Probable cause: You canceled a statement..." which is less than helpful since almost NO user interfaces give the user ANY facility to "cancel a statement"... even at the programming level, canceling a statement is usually a dream unfulfilled... killing a connection, maybe, but canceling a statement? Tell me how :)...
http://dcx.sybase.com/index.html#1101en/saerrors_en11/errm299.html
Request clarification before answering.
In JDBC, you can call Statement.execute()/executeQuery() to have the server start executing the statement and fetching the first row (if the statement returns a result set). If you then call Statement.cancel() on the same statement handle from a different thread, you effectively cancel the statement and the original thread that executed the statement will regain control with a -299 error message being returned from the server. That is basically what DBISQL does when you hit the stop button. So canceling a statement does make sense.
Now to answer your specific question. hitting the refresh button effectively calls cancel on the underlying database connection that the browser is making use of. Canceling the connection causes the statement that was executing to be canceled thereby returning the "interrupted" message. So yes, hitting refresh will/should result in the -299 error message.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Just to sum up: Canceling a statement is possible with ODBC, too, with the help of a second thread and the SQLCancel() ODBC API, cf. http://sqlanywhere-forum.sap.com/questions/608#624
@Breck: yes and no. The connection is not dropped until after the interrupted message is successfully returned to the client; so I'm not sure there is much danger involved here. Also, keep in mind that the user of the browser is not aware that there is a connection under the covers (since you don't actually "establish" one); but, since some SQL is executing, the user of the browser probably realizes that a statement is being executed, so the statement interrupted error does sort of make sense. Nevertheless, I will bring your concern up with the developer and see what he thinks.
@Breck and Volker: shut down hooks and global exception handlers are quite common in JAVA land. In both cases we are talking about secondary threads that are used to perform clean up or other similar work. So, I would think that having multiple threads in a JDBC application is quite common and in many cases necessary. I cannot say the same is necessarily true for ODBC applications, but I would not say that they are entirely uncommon in ODBC land either. JMO
@Karim: IMO there just needs to be a bit more in the Help topic on this SQLCode. I must confess, this exception (which NEVER goes back to the browser user, just shows up in application logs) has had me befuddled for a long time. I never connected it to browser refresh, even though it was me pressing refresh... possibly because it was always much later when I would look through the application exception logs for problems. Note that in the case of a web service the "client" is not a human being, it is an internal connection, so the "user" never sees this exception.
User | Count |
---|---|
33 | |
22 | |
17 | |
8 | |
5 | |
5 | |
4 | |
4 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.