[posted and mailed, please reply in news]
Steve (stevesusenet@yahoo.com) writes:[color=blue]
> I went to the microsoft site to try to find a guide to the error
> messages that the jdbc drivers give ( for sqlserver 2000 ).
>
> I had no luck.
>
> Does anyone know if there is such a guide?
>
> I got this mysterious error message below in my logs ( nothing visible
> in user land ).
>
> Anyone know what it means?
>
> java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for
> JDBC][SQLServer]Transaction (Process ID 151) was deadlocked on lock
> resources with another process and has been chosen as the deadlock
> victim. Rerun the transaction.[/color]
First, while the JDBC driver is the one that communicates the problem
to you, the error does not come from there. The last bracket says
[SQLServer], so this means that the error comes from SQL Server originally.
Had the error come directly from SQL Server, [SQL Server 2000 Driver
for JDBC] would have been the last bracket.
I don't know about any guides for JDBC driver messages, but the SQL
Server messages are all listed in Books Online, and some of the
errors also have topics which explains more about the error. There
is one problem in this case to find the error, because the far most
easiest way to look up an error is use the error number, and the
JDBC Driver does not seem to include that. (But it may be a property
of the execption - if exceptions can have properties in Java.)
One way to find the number is to issue something like:
SELECT * FROM master..sysmessages WHERE description LIKE '%deadlocked%'
from Query Analyser. (Replace %deadlocked%) with some other characteristic
part of the error message, but don't include object names, as they are
parameters to the messages and not available in sysmessages.
Now, this particular message has error 1205 and is a common error in
multi-user applications. What happens is that two connections are
both waiting for resources that are blocked by the other connection.
This situation is know as "deadlock". SQL Server detects this situation,
and selects one of the processes as a victim, and aborts its batch
and transaction.
Occasional deadlocks are nothing to lose sleep over, but if they are
frequent enough, this calls for a review of the the SQL code in the
application.
--
Erland Sommarskog, SQL Server MVP,
sommar@algonet.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp