No triggers, constraints

[jason_s_ford]

I have several sql server databases that were recently moved to a new
server. In the process of migrating the databases, any triggers and
constraints attached to tables were removed on accident. I need to add
these objects back into the databases, however I'm worried that I will
have problems with referential integrity since there is a chance
someone may have deleted or updated a record that should have cascaded
changes to other tables but did not since the triggers and constraints
were missing. Is there an easy way to check for problems of this
nature in the databases?

Also - I am planning on generating a script from the database on the
old server that scripts the triggers and constraints, and then use
Query Analyser to run this script against the database on the new
server. Is this the best way to add these objects back into databases
that are already populated with data and running on a live server?

In in a pretty bad position, but at least these are databases that are
not accessed too frequently, so I'm hoping any referential integrity
problems will be minor.
Any help or advice would be greatly appreciated.

[Simon Hayes]

<ja**********@hotmail.com> wrote in message
news:10**********************@c13g2000cwb.googlegr oups.com...

I have several sql server databases that were recently moved to a new
server. In the process of migrating the databases, any triggers and
constraints attached to tables were removed on accident. I need to add
these objects back into the databases, however I'm worried that I will
have problems with referential integrity since there is a chance
someone may have deleted or updated a record that should have cascaded
changes to other tables but did not since the triggers and constraints
were missing. Is there an easy way to check for problems of this
nature in the databases?
Not really, since in order to check this you would need to know the
primary/foreign keys that should be there anyway. So you might as well just
add them back again, and see if you get any errors. Triggers are a bit more
of a problem, but if you're only using them for RI, then hopefully adding
the foreign keys will pick up any problems. If you have more complex
business rules in triggers, then there are no real shortcuts except to work
through your logic and see if any data is incorrect - hopefully you don't
have too many...
Also - I am planning on generating a script from the database on the
old server that scripts the triggers and constraints, and then use
Query Analyser to run this script against the database on the new
server. Is this the best way to add these objects back into databases
that are already populated with data and running on a live server?
That's fine. If the script is large, make sure you run it in chunks to avoid
getting too many errors back in one go. And of course try it out on a test
copy of the database first.

In in a pretty bad position, but at least these are databases that are
not accessed too frequently, so I'm hoping any referential integrity
problems will be minor.
Any help or advice would be greatly appreciated.

For the future, you might want to review how you move databases to new
servers (backup/restore is usually an easy option, and you can't lose
anything that way), and perhaps look at some schema comparison tools, which
can help you find and fix schema issues. This one is quite good, but there
are plenty of others:

http://red-gate.com/SQL_Compare.htm

Simon