We run an ASP website with an MS SQL Server database on a third party
server.
Last night it was hacked and data in one table, called Entry, was changed.
I exported the database to my local server (as local1) and corrected the
data changes.
I then tried to import it back to the remote server and that failed - it
didn't transfer the Entry table for some reason and then complained that it
couldn't find it.

After much trial and error I set up a new empty database (s2) on the remote
server, and created a new one locally (called new1) with new dummy data of
approx the same size. I was then able to import new1 into s2 successfully.
I then tried importing the old database local1 into the new server s2 and
that failed as before. I then tried to re-import new1 into s2 and that
failed this time although it was fine before.
So it seems that the old database is somehow "corrupting" the new one.
Can someone please suggest what might be happening and how I get round this?
I find the log files not much help and am very keen to get our system back
live.
Thanks in advance,
Peter Croft

Can you run DBCC Check DB and See if something going wierd also run DBcc
repair to fix it fast before doing any importing.

"Peter Croft" wrote:

I ran DBCC CheckDB and it was fine.
I found this message generated in a log at some point -
::Error::
Transfer Status: Scripting Tables
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]ConnectionRead (recv()).
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]General network error.
Check your network documentation.
so I guess it is a comms problem but I don't know how to get more info. How
do I find out where the problem lies? I am also unclear why it's ok for some
tables but not for others. The main difference seems to be row size.
Peter


"SP" <SP (AT) discussions (DOT) microsoft.com> wrote