John Sheppard (spam@nospam.com) writes:
> It's dropping tables and recreating them....I dont understand the use of
> synching software that does that, I need the data intact

There is nothing wrong as such with dropping and recreating tables. For
some changes this is necessary, as ALTER TABLE cannot do everything.

But of course, the tool needs to cater for the data being copied over
to the new table. And of course the tools need to do this safely, and
make sure that indexes, triggers etc are restored. All and all, it's more
complex and risky. But it is a concept that a tool has to master. As it
is for someone who is working a lot with table changes, because you
will run into the situation sooner or later.

> I think a transaction logger is gonna have to be the go...

And capture all sorts of junk commands that you issue? Why not just Profiler
or a server-side trace instead?



--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx