Backup fails with ConnectionRead (WrapperRead()

For the past week my maintenance plan that backs up the
master and my main database has been failing, but only on
my database. The master backup works fine. The plan fails
when trying to execute:
BACKUP DATABASE [WebTools] TO DISK = N'G:\SQLBackup\WebTools\WebTools_db_200310290834.BAK'
WITH INIT , NOUNLOAD , NOSKIP , STATS = 10, NOFORMAT
When I try running this command via Enterprise Manager, it
reports a syntax error "WITHINIT" (no space). I removed
all the WITH settings and re-ran it, but then it failed
with a ConnectionRead error.
Using Query Analyzer, the command runs for a few seconds
and then reports the error:
[Microsoft][ODBC SQL Server Driver][Shared Memory]
ConnectionRead (WrapperRead()).
Server: Msg 11, Level 16, State 1, Line 0
General network error. Check your network documentation.
THe backup, however, continues and completes successfully
according to Event Viewer.
Can anyone shed some light on this? TIA.
I'm running W2K SP4, SQL2K SP3 on a Dell 2600 with a Xeon
processor (which looks like 2 CPUs).Hello David,
I would appreciate your patience while I am looking into this issue. I'm now performing some
troubleshoots on your issue and will post my response at soon as I have update for you.
Thanks for posting to MSDN Managed Newsgroup.
Regares,
Billy Yao
Microsoft Online Partner Support|||Hi David,
Thank you for using MSDN Newsgroup! It's my pleasure to assist you with your issue.
From your description, I understand that your maintenance plan failed for database backup
errors. Therefore, you performed the backup manually but another network error occurred.
However, the backup did succeed according to your event log.
Have I fully understood you David? If there is anything I misunderstood, please feel free to let
me know.
Considering the backup did succeed and the network error is so general, I suspect that the
issue is located in the network library. It is recommended that you apply the latest MDAC 2.8 to
suppress this symptom. You can download this MDAC via:
http://www.microsoft.com/downloads/details.aspx?FamilyID=6c050fe3-c795-4b7d-b037-
185d0506396c&DisplayLang=en
If you use Named Pipes Net-Library to connect to the SQL Server database, I strongly
recommend you use the TCP/IP Net-Library instead.
For the exact steps to set the TCP/IP network library on the client where you are performing the
backup or the restore operation, see the "How to configure a client to use TCP/IP (Client
Network Utility)" chapter in SQL Server 2000 Books Online.
When you connect to an instance of SQL Server by using SQL Query Analyzer, you can force
the connection to use the TCP/IP Net-Library. To do this, type the name of the instance of SQL
Server with the tcp prefix in the SQL Server text box in the Connect to SQL Server dialog box.
This appears as follows:
tcp:SQL Server Name
Another possible cause of backup failure is that there was no space in the disk drive due to
the fact that the transaction logs were not got truncated. In this case, the logs may fill up disk
space, and you need to shrink the transaction log files first.
To resolve this problem, please follow the steps in the following articles to truncate the
transaction log
272318 INF: Shrinking the Transaction Log in SQL Server 2000 with DBCC
http://support.microsoft.com/?id=272318
David, please apply the suggestions above and let me know if it helps you resolve your
problem. If there is anything more I can assist you with, please feel free to post it in the group.
Best regards,
Billy Yao
Microsoft Online Partner Support
----
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.|||Thanks Billy.
First... I had already installed MDAC 2.8 as part of an
attempt to resolve a different problem, and disk space
wasn't an issue.
I then tried to use QA to connect via TCP to SQL Server,
but couldn't. I checked the network settings in SQL Server
and it indicated both Named Pipes and TCP/IP were
available. When I checked the log, however, it said it was
only listening on the named pipes.
I did some more digging, but nothing fixed that problem. I
wound up removing SQL Server from the system and re-
installing it from scratch. The log showed it was now
listening on TCP as well. When I tried the backups via QA
and the maintenance plan, both worked.|||Dear David,
Thank you for your good news!
I'm glad that the problem was solved by re-installing the SQL Server. I
think the cause of SQL Server not listening on TCP may be related to some
register key was revised with some unexpect reasons (such as by some
applications).
Anyway, I appreciate your logical troubleshooting and congratulations on
your finding the cause and solve the problem.
Thank you for participating our newsgroup!
- Billy