Matt White (mj*@cbord.com) writes:
We've found deadlocks in the trace file that were not captured by our
Powerbuilder application. Some deadlocks are trapped or, at least,
reported to the user as a db error, and others are completely silent.
We've also seen evidence of strange data that would be explained by
unprocessed deadlocks, although we've not yet proven that the
unreported deadlocks are killing updates to the db.
Putting a raiserror into various parts of the same code (and code
review) appears to prove that we are error checking after each db
update. That is, it looks like we're checking, and a raiserror always
bubbles up to the app.
Can anyone shed some light on a.) How this could happen and b.) What
Should We Do?
It may be more of a PowerBuilder issue than an SQL Server issue.
PowerBuilder may be doing something "smart" with deadlocks. The
deadlocks may also come in a situation where PowerBuilder is not prepared
for them.
To tell a war story, we had problem with RDO in Visual Basic and SQL 6.5.
We had a customer who occasionally would get half-baked transactions,
and strangely only the latter part of it, but we could not figure out
why. Eventually another customer went live, and they had a lot more
deadlocks. Eventually we found that when you sent bare SQL statements to
SQL Server, RDO would generate temporary stored procedures for this, and
often the dropping of these procedures caused a deadlock that rolled
back the transaction. But RDO failed to raise an error to the VB code,
so we just jogged along merrily, now without a transaction.
--
Erland Sommarskog, SQL Server MVP,
es****@sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp 
