|
|
Posted by Erland Sommarskog on 10/01/88 11:26
Nick Stansbury (nick.stansbury@sage-removepartners.com) writes:
> Thanks for your help. Setting aside the issue over identity column
> incrementation (although I'm going to beat them up to try and get them to
> admit to doing something funny - a restore / detached database) - is there
> anyway this could be caused by implicit transactions being turned on?
First I like to stress, that since you can see that the IDENTITY column
does not have a gap, we can rule out this possibility.
But we assume that we did not have this fact, if someone had enabled
IMPLICIT_TRANSACTIONS, and the application does cater for this, you
would get this effect. Most of the ANSI settings has a database setting,
but IMPLICIT TRANSACTIONS has not - at least not one that is documented.
It is possible configure this on server level, though.
There is a more common scenario that can have the same effect. The
application calls a stored procedure that starts a transaction and
then gets blocked. The application times out after 30 seconds - the
default timeout in several client APIs. The timeout does not roll
back the transaction automatically, and the application code ignores
to do it. The effect is that the user continues to work, and everything
looks fine. But when the user disconnects, all data entry is lost.
But all that is all theoretic. If you have a real IDENTITY column in
that table, this did not happen, because then we would have seen gaps,
as the IDENTITY numbers taken are not rolled back.
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp
Navigation:
[Reply to this message]
|