|
|
Posted by John Bell on 09/30/12 11:26
Hi Nick
You may have information in the Web logs that shows that your colleague
carried out this work so make sure they are preserved.
If you can view the SQL Agent scheduled jobs then you might be able to see
what is carried out on your database.
John
"Nick Stansbury" <nick.stansbury@sage-removepartners.com> wrote in message
news:dfuqg4$4gn$1@pop-news.nl.colt.net...
> 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]
|