CODEWITHSUNDEEP
c#sql-serverasp.net-mvcentity-frameworksql-server-2008r2-express
Daniel
Daniel

Reputation: 71

Handling Intermittent SQL Timeout/Network Errors

I am working on an MVC application that connects to MS SQL Server 2008 R2. The development server is the Express Version - I don't know if that is a contributing factor...

Intermittently, when I run the application from Visual Studio (so it opens in Chrome), I get errors connecting to SQL Server.

Errors such as:

This is my connection string (I changed a few words in it before posting it publicly)

<add name="[MyEntities]" 
    connectionString="metadata=res://*/Models.[publicword].csdl|res://*/Models.[publicword].ssdl|res://*/Models.[publicword].msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=thanos;initial catalog=[DatabaseName];Integrated Security=SSPI;multipleactiveresultsets=True;application name=EntityFramework&quot;"
    providerName="System.Data.EntityClient" />

I have searched via Google quite a bit, without finding anything especially helpful - I am trying to figure out how I could make my application retry once when it gets a connection error, rather than failing, considering it almost always works on the second try.

Any suggestions of where to start? I don't have access to mess with the server as an Admin but if that's the place to address this, I can probably coordinate with the person who is an Admin.

I am considering it possible that this is somewhat related to running the application locally - the database is on a server some miles away from where I am located. Once the application is deployed to the server, the application will be running on the same physical box as the database. But I don't feel good enough about that to assume that everything will be fine - I don't want to get to Production with this assumption just to find out I was wrong...

Upvotes: 0

Views: 896

Answers (1)

PhillipH
PhillipH

Reputation: 6222

Is there any reason you dont handle the intermittent timeout by a retry block ? If in reality your database might be non-geolocated then IP lag and other network anomolies may well interfere with your ability to connect on a sporadic basis.

As a similar example the standard practise on connecting to a SQL Azure database is to always connect in retry block, mainly for throttling reasons rather than network failure, but its quite common practise to handle intermittent failures this way.

Upvotes: 1

Related Questions