Re: WARNING. A simple cut and paste of 8 records can distroy a SQL Server table

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Beeeeeves (beeeeeeeeev_at_ves)
Date: 06/20/04 

Date: Sun, 20 Jun 2004 11:37:53 +0100

If you have a field name of more than 900 characters, then its your own
silly fault.
On the other hand it could be that you had a unique index on that was
created with(nocheck), which would explain why you could delete records, but
couldn't put them back in again.

"pete" <pete@madpete.freeserve.co.uk> wrote in message
news:40d2c64e$0$4584$db0fefd9@news.zen.co.uk...
> Today I need to copy 8 records in a table. I have to use Access 200
because
> of the limitation of Enterprise Manager's inability to cope with field
with
> more than 900 characters. Selected records, cut, paste. I got an erroor
> message about not being able to have a null Key_ID (I copied the reords
and
> tried to paste the Key_ID as part of the records - normally I hide the
> Key_ID).
> Now I can't access either the new records or the originals that I was
trying
> to copy (because, it would seem, they have identical primary keys). I also
> cannot export the table via DTS 'unspecified error' and 'integrity
> violation'.
> Or delete the offending records with a Query Anaylyser delete query.
> Basically the entire SQL Server database has been destroyed with a couple
of
> keystrokes.
> Now, I've being developing database applications for over 20years and the
> one thing, maybe the only thing I expect from a database server is to
> protect the integrity of my data. SQL Server does not, it would seem.
These
> records aren't just any random unimportant records either. They contain
the
> 'create views' that my entire application require to function and each one
> approaches the 8000 record limit and have take years to perfect and just
> checking that the table is valid could take me days.
>
>

Relevant Pages