|
|
Posted by Nick Stansbury on 10/01/96 11:26
Dear Erland,
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?
I don't know anything at all about implicit transactions - but it seems
logical that they could mean that if a connection crashed then none of the
data entered in that connection would be entered? Is there anyway to check
this possibility (i.e. prove that it had nothing to do with transactions?)
Nick
> 1) A backup was restored. (Or some variation thereof)
> 2) Due to application error, the transaction was never committed, and
> when the user disconnected, it was rolled back.
>
> However, here is an important piece of information:
>
> > 2) There is no perceivable break in our identity columns. So despite the
> > fact that I know he entered 7 new customers, I can go back through the
> > customers table and look at where those customers should sit visa vie
> > entry times - and it's just as though the customers he entered never
> > existed - sql server just keeps incrementing sequentially and there's no
> > break - so the last customer entered at about 6:50 pm was something like
> > number 11912 and the customers entered this morning have numbers that
> > carry on from 11913.
>
> Assuming that this columns really have the IDENTITY property, then this
> rules out the second possibility. IDENTITY numbers are not affected by
> transaction scope. Had the transaction never been committed, you would
> have seen a gap.
>
> > 3) I'm running in a shared environment - the server is hosted by a
> > webhosting company (who shall remain nameless unless I can prove it's
> > their fault!)
>
> They are indeed highly suspect. It appears that they restored the database
> to the state of 18:50 or whereabouts. If you have access to msdb, you
> can check the table restorehistory. (There is a second possibility that
> will not show up in this table. Say that they detached the database,
> copied it to another server, reattached it, and not until later repointed
> the server, causing your clerk to work in a dead end.)
Navigation:
[Reply to this message]
|