Error while running RESTORE DATABASE

fishusa

Hello,

I'm trying to use the sqb2mtf.exe program to restore our databases to a development server. Sqb2mtf works fine, and generated 32 .BAK files (we run SQL Backup at 32 threads). When I try to restore the database back to SQL Server 2000 on the development server, I get the following error

[Microsoft][ODBC SQL Server Driver][Shared Memory]ConnectionCheckForData (CheckforData()).
Server: Msg 11, Level 16, State 1, Line 0
General network error. Check your network documentation.

Connection Broken

The code I am trying to execute is

 RESTORE DATABASE Tackleshop from 
disk='g:\backup~1\dbs\tackleshop_00.bak', 
disk='g:\backup~1\dbs\tackleshop_01.bak', 
...
disk='g:\backup~1\dbs\tackleshop_31.bak'

My database is roughly 4 GB compressed, 32 GB uncompressed (I know, *huge*). Has anyone experienced any problems like this before? Perhaps I am running out of memory? I'm not sure.

Thanks in advance.

J.R. Murray
FishUSA.com - America's Tackle Shop!

Chris.Allen

For now, can I just ask- is drive "g:" mapped to a network drive?
If so, is that connection relaible at the moment?

fishusa

No, G: is a logical partition.
Thanks.
J.R. Murray

Chris.Allen

Ok, so I'm doubting that that is the cause of the problem then.

I'm still working under the assumption that it is a network problem though- so are you restoring to a network drive?

I did some googling of that error message and found this:

http://blog.sqlauthority.com/2008/04/10 ... df-part-2/

Could this apply in your situation?

Are you able to restore from the file originally created by SQL Backup?

fishusa

I am not restoring on a network drive, only on a local HDD. The only reason I'm using G: instead of the C:\..\MSSQL\Data directory is because of size, although I don't think that should make a difference.

I have not tried to restore the original file to the live server because...well its the live server, lol. It seems to load up fine in SQL Backup. I'm going to hunt around and see if SQL Backup has a validation tool for its SQB files. I suppose its possible that the SQB file is corrupt, however, it would seem more like the file is too big to be processed by SQL server or something to that effect.

Thanks.
J.R. Murray
FishUSA.com

Chris.Allen

OK, I'll keep an eye on this post and let you know if I come up with something more concrete to help you.

fishusa

Thanks!!

Chris.Allen

The next suggetsion we have is to check the SQL Server ERRORLOGs... Te reason why it crashes waiting for data could be that SQL Server is killing the SPID of the restore process. Checking for errors on the server-side, rather than the client-side would probably be worth a shot.