• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2167
  • Last Modified:

[Microsoft][ODBC SQL Server Driver]Protocol error in TDS stream

I've got a Server2008 SP1 32 bit server using ODBC to connect to Server2012 running SQL2012.  It runs some file build utilities that have worked fine until 3 days ago and then I got the error in the title.  Both servers run on VMware boxes with dual port twinax 10 GB NICs.

I ran Windows Updates on the Server2008 box, but it didn't change anything.  

I could use some help.
Scott Miller
Scott Miller
  • 4
1 Solution
Chad FranksSenior System EngineerCommented:
was something changed on the network side?  I have seen this when the switch/nics didn't match their duplex...
Scott MillerIT ManagerAuthor Commented:
Nope.  We upgraded to SQL2012 a couple of weeks ago and it has run perfectly since.....up until 3 days ago.

I just upgraded the Server2008 (where the processes run and get the errors) to SP2.  It ran the processes fine the first time and errored out on the second time and nearly every time after.
Scott MillerIT ManagerAuthor Commented:
ODBC timeout issue.  Why it suddenly stopped working, I don't know.  I increased the timeout to 120 seconds and it's worked perfectly every time I've tested it since.

8/21/14 - I lied ;)  
I've still got one file rebuild that causes the above error.  I'll increase the timeout to 180 and see if that helps.  The last timeout increase got the error from 2-3 times down to one, so I think I'm on the right track.

8/21/14 - I lied again.  I changed the ODBC timeout settings yesterday, but today when I thought I'd change them again to a higher value - the ones I set yesterday were gone and it's back to default.  Not sure what to do at this point.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Scott MillerIT ManagerAuthor Commented:
8/22/14 - trying a different approach, I changed the timeout on the TCPIP configuration on the SQL server.  
Yesterday, things ran fine manually, but when I set them up to run automatically (like normal), I started getting the error back again.  I ran all the processes manually today and they worked fine.  I'm in the midst of running them for the third time automatically; so far, no errors.  

Stay tuned.......
Scott MillerIT ManagerAuthor Commented:
Figured it out.  I've got 5 VMware servers.  VM1 is where the S2008 server that runs the processes resided.  VM2 is where the SQL2012 server resides.  VMware manages the 20GB connections from the servers to the switch, so when other servers on the VM1 box got busier, they took some of the bandwidth that the S2008 server was using, causing a slowdown in bandwidth, which caused the error.  That also shows why the problem was intermittent; when the other servers on VM1 were less busy, the processes ran fine; when they were more busy, the processes had the errors.  
I moved the S2008 server in question onto VM2 where the SQL2012 server resides - problem solved.  There's no worry about interference because it runs at bus speed.  I've tested it half a dozen times flawlessly and even let it run at it's normally scheduled time.

This question can be closed.  

I won't accept my own answer as the solution (even though it was) because there people here that think I've done that to build up my own points.  I don't care about points, I care about getting my issue resolved.
Seth SimmonsSr. Systems AdministratorCommented:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now