I have not seen this before and am not quite sure where to start as I cannot reproduce it, it is happening on average once a day. Any ideas what this is typically or where to start looking?






Keith Chisarik

Everything I have googled about this says that it is a problem with commands that can take a significant amount of time to execute, so people will set the CommandTimeout property to a larger number and the process completes successfully.  However, if you're just opening the connection, then something else might be wrong.  Does this error come back immediately, or does your computer wait for 15 or 30 seconds before throwing the error?

This process runs every 3 minutes, 24 hours a day.



I haven't caught it to see when it does it. It looks to me like the call to the BO save throws the error, the system is designed to only save changed records which at most might be several hundred out of only 15,000 total records. I would think it could update all of them and not even blink. This system is the most data intensive I have done with SF so it is possible I have something wrong. Hard to catch it when you can't reproduce though.



It does open a connection to a remote DB2 database over HTTP, so that certainly could be slow but unless I am mistaken this errors occurs much further down the processing tree on the final save of any changes between the DB2 "live data" and my SQL catalog of that data and I am not using SF objects for the DB2 data.



So I guess the simplest question, do you agree this error is being generated to the save() call against the BO?

Keith Chisarik

Hey Keith, it looks as though the error is just manifesting itself through the Save....but the actual error is happening on the backend through the connection in the DAL.  The error is actually happening within the System.Data.SqlClient.TdsParserStateObject.ReadSniSyncOverAsync method.  It seems that one of two things could be happening:

1. The connection has already been established but the process is taking a long time.  This can happen if you are using a standard SQL Server connection to a remote site via a VPN connection.  The TDS stream is actually very large and there would be no compression either, so if there were a lot fo records being save and there was any type of latency in the network or internet connection, then a timeout could be happening.  In this cas you would need to beef up the connection timeout to more than 30 seconds (the default) by modifying the connection string of the SQL connection.
2. Something within the TDS stream (the update tag) is causing the error.  In this case you would want to turn on data debugging to see what is going back to the server....I will tell you that I think this is not as likely as number 1 above.

This is one reason the Enterprise Server is extremely beneficial when talking with remote data sources....it is fast!  All of the TDS data, encryption, and compression is applied and there is an absolute minumum of data going across the wire.

It is that age old problem...if you can reproduce it you can fix it

The SQL Server is local. Do you still think #1 is most likely?

Keith Chisarik

Yeah....it seems that there is a timeout occuring.  The number one thing before tearing stuff apart, as I have learned from experience , is to reproduce the problem.  There is no reason to start making changes until you can definitively reproduce the problem so you can determine if you have resolved the problem...or made it worse

I had an issue with our medical software this last week that I could not reproduce my knew it was happening in certain conditions.  I just kept on it until I finally made it fail...then I figured out how to make it fail consistently.  Once I had this issue in a repeatable state it was a relatively easy fix and I knew it was a reliable fix.

I know this is all stuff you already know...but I think the first order of business is to reproduce the problem consistently.