This article was previously published under Q276039
This article has been archived. It is offered "as is" and will no longer be updated.
BUG #: 57658 (SQLBUG_70)
Two or more SQL Data Manipulation Language (DML) statements issued from different SQL connections experience erroneous blocking or deadlocking for a given index key lock. The problem can be seen:
With the key lock type.
When the resource looks like (xxxx00000000). Such resource hashing is symptomatic of this problem.
NOTE: DML statements include SELECT, INSERT, UPDATE, and DELETE.
When SQL Server places a lock on an index key, the key is "hashed down" to a six byte lock resource, which is used by the lock manager to lock the respective key in the required mode. In this case, a duplicate hash value was incorrectly generated for two distinctly different index keys when taking a key lock in a non-unique index. This can cause an SQL DML statement to block erroneously if a collision occurs between a valid and errant hash value and their respective lock modes are incompatible.
This problem will only manifest itself with key locks.
The net effect of this bug is that the server is "overlocking". It is important to note that data integrity is not in any way compromised.
Microsoft has confirmed this to be a problem in SQL Server 7.0. This problem has been corrected in U.S. Service Pack 3 for Microsoft SQL Server 7.0. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
274799 INF: How to Obtain Service Pack 3 for Microsoft SQL Server 7.0 and Microsoft Data Engine (MSDE) 1.0
For more information, contact your primary support provider.