I will get errors like this below at random points as we are running our app.

Message from elmah:

System.Data.SqlClient.SqlExceptionDatabase '......' on server '........' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of '.........'.

Top message in stack trace:

System.Web.HttpUnhandledException (0x80004005): Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.Data.Entity.Core.EntityException: An exception has been raised that is likely due to a transient failure. If you are connecting to a SQL Azure database consider using SqlAzureExecutionStrategy. ---> System.Data.Entity.Core.EntityException: The underlying provider failed on Open. ---> System.Data.Entity.Core.EntityException: An exception has been raised that is likely due to a transient failure. If you are connecting to a SQL Azure database consider using SqlAzureExecutionStrategy. ---> System.Data.SqlClient.SqlException: Database '......' on server '.......' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '......'.

I've dug into this and have created the following class to use the configuration below against my database

    public class SqlAzureDBConfiguration : DbConfiguration 
    {
        public SqlAzureDBConfiguration() 
        { 
            SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy(10, TimeSpan.FromSeconds(15))); 
            SetDefaultConnectionFactory(new LocalDbConnectionFactory("v11.0")); 
        } 
    } 

I've also modified my web.config file to use the configuration.  

Since the error is that the server does not exist (and I know that it does), I assume that there is some type of intermittent error that is happening in the azure cloud's internal network between the web server and the database server.  The web and db server are setup in the same region.  We have had this happen two times during the testing of azure over the last three months.  

I am trying to get the connection to retry if it does not first connect.  Given that both times we have had this, the error has lasted about a minute, I'd like to retry every 10 seconds for the next 150 seconds just to see if we can connect.  Unfortunately, this does not appear to be working properly.  When I disconnect from the wireless here at my office, I get an error here after about 15-20 seconds regarding attempting to connect to the sql azure db.  It would seem to me that the class SqlAzureExecutionStrategy is going to handle the execution of commands.  Am i correct in this?  Is there a way to handle transient failed connections?  is there something else that I need to do to cause a retry?  Any suggestion is appreciated.

Thanks,

Wally

Hi Wally,

Apologies for the inconvenience.

Are you still having the issue? Which region is your database hosted in? Are you using the V12 database?

We did have a SQL Database Service Incident in West US.

[5/27/2015 11:04:18 PM PDT]  - From 27 May, 2015 21:14 to 28 May, 2015 05:44 UTC customers using V12 SQL Database in West US might have experienced errors when attempting to perform CRUD operations (create, rename, update or delete).  Current SQL runtime operations were not impacted by this issue. This incident has now been mitigated.

Regards,

Mekh. 

Mekh,

Thank you for response.  We had the issue for approximately one minute on Wednesday.  The error occurred on May 27 at 11:15 pm UTC.  Our web server is setup for US East and our database is setup for US East.  This is the second time that we have seen this error.  The first time we did not have elmah up and storing the errors.  We are using the V12 database.  I updated the database back at the beginning of May.  We have run several tests since then with no issues.

The session id for the error was: 75ED8932-DBF8-4151-817D-5339BABA7B23

Questions:

• Is there any way to detect that an error on a connection open occurred and to have the connection auto retry?   The error message that I got and pasted into the first message implies that this is possible via SqlExecutionStrategy.  I am unsure on this due not seeing anything that looks like a sql connection retry option.  I only see retry options that appear to be for commands.
• I have thought about implementing queuing for saving data, however, I am concerned that the error is really a network error in disguise.  if that is the case, we won't have access to the network anyway.  Any thoughts on this?
• if you have any additional suggestions, feel free to share.

Any more thoughts on this? Thanks.

Hello Wally,

I am a Program Manager with the connectivity team on Azure SQL DB and I will look into this for you. To answer your questions, the best thing to do would be file a support ticket. That way our engineering team will be able to take a look at that. However this seems like a retry logic issue and can be fixed by implementing the appropriate retry logic strategy. 

Here is what I would recommend:

Please follow the following blog posts to implement retry logic(These are ADO.NET samples but you can replicate the logic in the language of your choice)

https://msdn.microsoft.com/library/azure/ee336243.aspx

https://msdn.microsoft.com/en-us/library/azure/dn961167.aspx

If these do not do the trick, I would love to get in touch with you. Please email me at mebha at microsoft dot com

Happy to help!

Best,

Meet Bhagdev

Program Manager, Microsoft

• Edited by Meet BhagdevMicrosoft employee 12 hours 23 minutes ago

Hello Wally,

I am a Program Manager with the connectivity team on Azure SQL DB and I will look into this for you. To answer your questions, the best thing to do would be file a support ticket. That way our engineering team will be able to take a look at that. However this seems like a retry logic issue and can be fixed by implementing the appropriate retry logic strategy. 

Here is what I would recommend:

Please follow the following blog posts to implement retry logic(These are ADO.NET samples but you can replicate the logic in the language of your choice)

https://msdn.microsoft.com/library/azure/ee336243.aspx

https://msdn.microsoft.com/en-us/library/azure/dn961167.aspx

If these do not do the trick, I would love to get in touch with you. Please email me at mebha at microsoft dot com

Happy to help!

Best,

Meet Bhagdev

Program Manager, Microsoft

• Edited by Meet BhagdevMicrosoft employee 12 hours 12 minutes ago

I have been having the same problem for the last few hours with a database in Northern Europe

ex = {"Database 'CompanyFile' on server 'hector' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '12AAB1B5-059C-402B-B057-436EA7FB8E92'

We use retry logic and it has been working fine for months. The database was created as V12 Preview.

We can no longer connect via our app or SSMS. According to the management portal the database is active.

• Edited by Emp Nr 852534 8 hours 25 minutes ago

I have been having the same problem for the last few hours with a database in Northern Europe

ex = {"Database 'CompanyFile' on server 'hector' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '12AAB1B5-059C-402B-B057-436EA7FB8E92'

We use retry logic and it has been working fine for months. The database was created as V12 Preview.

We can no longer connect via our app or SSMS. According to the management portal the database is active.

• Edited by Emp Nr 852534 8 hours 35 minutes ago

Hello Wally,

I am a Program Manager with the connectivity team on Azure SQL DB and I will look into this for you. To answer your questions, the best thing to do would be file a support ticket. That way our engineering team will be able to take a look at that. However this seems like a retry logic issue and can be fixed by implementing the appropriate retry logic strategy. 

Here is what I would recommend:

Please follow the following blog posts to implement retry logic(These are ADO.NET samples but you can replicate the logic in the language of your choice)

https://msdn.microsoft.com/library/azure/ee336243.aspx

https://msdn.microsoft.com/en-us/library/azure/dn961167.aspx

If these do not do the trick, I would love to get in touch with you. Please email me at mebha at microsoft dot com

Happy to help!

Best,

Meet Bhagdev

Program Manager, Microsoft

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 03, 2015 6:55 PM

Hello Wally,

I am a Program Manager with the connectivity team on Azure SQL DB and I will look into this for you. To answer your questions, the best thing to do would be file a support ticket. That way our engineering team will be able to take a look at that. However this seems like a retry logic issue and can be fixed by implementing the appropriate retry logic strategy. 

Here is what I would recommend:

Please follow the following blog posts to implement retry logic(These are ADO.NET samples but you can replicate the logic in the language of your choice)

https://msdn.microsoft.com/library/azure/ee336243.aspx

https://msdn.microsoft.com/en-us/library/azure/dn961167.aspx

If these do not do the trick, I would love to get in touch with you. Please email me at mebha at microsoft dot com

Happy to help!

Best,

Meet Bhagdev

Program Manager, Microsoft

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 03, 2015 6:55 PM

Hello Wally,

I am a Program Manager with the connectivity team on Azure SQL DB and I will look into this for you. To answer your questions, the best thing to do would be file a support ticket. That way our engineering team will be able to take a look at that. However this seems like a retry logic issue and can be fixed by implementing the appropriate retry logic strategy. 

Here is what I would recommend:

Please follow the following blog posts to implement retry logic(These are ADO.NET samples but you can replicate the logic in the language of your choice)

https://msdn.microsoft.com/library/azure/ee336243.aspx

https://msdn.microsoft.com/en-us/library/azure/dn961167.aspx

If these do not do the trick, I would love to get in touch with you. Please email me at mebha at microsoft dot com

Happy to help!

Best,

Meet Bhagdev

Program Manager, Microsoft

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 03, 2015 6:55 PM

Hello Wally,

I am a Program Manager with the connectivity team on Azure SQL DB and I will look into this for you. To answer your questions, the best thing to do would be file a support ticket. That way our engineering team will be able to take a look at that. However this seems like a retry logic issue and can be fixed by implementing the appropriate retry logic strategy. 

Here is what I would recommend:

Please follow the following blog posts to implement retry logic(These are ADO.NET samples but you can replicate the logic in the language of your choice)

https://msdn.microsoft.com/library/azure/ee336243.aspx

https://msdn.microsoft.com/en-us/library/azure/dn961167.aspx

If these do not do the trick, I would love to get in touch with you. Please email me at mebha at microsoft dot com

Happy to help!

Best,

Meet Bhagdev

Program Manager, Microsoft

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 03, 2015 6:55 PM

Hello Wally,

I am a Program Manager with the connectivity team on Azure SQL DB and I will look into this for you. To answer your questions, the best thing to do would be file a support ticket. That way our engineering team will be able to take a look at that. However this seems like a retry logic issue and can be fixed by implementing the appropriate retry logic strategy. 

Here is what I would recommend:

Please follow the following blog posts to implement retry logic(These are ADO.NET samples but you can replicate the logic in the language of your choice)

https://msdn.microsoft.com/library/azure/ee336243.aspx

https://msdn.microsoft.com/en-us/library/azure/dn961167.aspx

If these do not do the trick, I would love to get in touch with you. Please email me at mebha at microsoft dot com

Happy to help!

Best,

Meet Bhagdev

Program Manager, Microsoft

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 03, 2015 6:55 PM

Hello Wally,

I am a Program Manager with the connectivity team on Azure SQL DB and I will look into this for you. To answer your questions, the best thing to do would be file a support ticket. That way our engineering team will be able to take a look at that. However this seems like a retry logic issue and can be fixed by implementing the appropriate retry logic strategy. 

Here is what I would recommend:

Please follow the following blog posts to implement retry logic(These are ADO.NET samples but you can replicate the logic in the language of your choice)

https://msdn.microsoft.com/library/azure/ee336243.aspx

https://msdn.microsoft.com/en-us/library/azure/dn961167.aspx

If these do not do the trick, I would love to get in touch with you. Please email me at mebha at microsoft dot com

Happy to help!

Best,

Meet Bhagdev

Program Manager, Microsoft

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 03, 2015 6:55 PM

Hello Wally,

I am a Program Manager with the connectivity team on Azure SQL DB and I will look into this for you. To answer your questions, the best thing to do would be file a support ticket. That way our engineering team will be able to take a look at that. However this seems like a retry logic issue and can be fixed by implementing the appropriate retry logic strategy. 

Here is what I would recommend:

Please follow the following blog posts to implement retry logic(These are ADO.NET samples but you can replicate the logic in the language of your choice)

https://msdn.microsoft.com/library/azure/ee336243.aspx

https://msdn.microsoft.com/en-us/library/azure/dn961167.aspx

If these do not do the trick, I would love to get in touch with you. Please email me at mebha at microsoft dot com

Happy to help!

Best,

Meet Bhagdev

Program Manager, Microsoft

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 03, 2015 6:55 PM

Hello Wally,

I am a Program Manager with the connectivity team on Azure SQL DB and I will look into this for you. To answer your questions, the best thing to do would be file a support ticket. That way our engineering team will be able to take a look at that. However this seems like a retry logic issue and can be fixed by implementing the appropriate retry logic strategy. 

Here is what I would recommend:

Please follow the following blog posts to implement retry logic(These are ADO.NET samples but you can replicate the logic in the language of your choice)

https://msdn.microsoft.com/library/azure/ee336243.aspx

https://msdn.microsoft.com/en-us/library/azure/dn961167.aspx

If these do not do the trick, I would love to get in touch with you. Please email me at mebha at microsoft dot com

Happy to help!

Best,

Meet Bhagdev

Program Manager, Microsoft

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 03, 2015 6:55 PM

Hello Wally,

I am a Program Manager with the connectivity team on Azure SQL DB and I will look into this for you. To answer your questions, the best thing to do would be file a support ticket. That way our engineering team will be able to take a look at that. However this seems like a retry logic issue and can be fixed by implementing the appropriate retry logic strategy. 

Here is what I would recommend:

Please follow the following blog posts to implement retry logic(These are ADO.NET samples but you can replicate the logic in the language of your choice)

https://msdn.microsoft.com/library/azure/ee336243.aspx

https://msdn.microsoft.com/en-us/library/azure/dn961167.aspx

If these do not do the trick, I would love to get in touch with you. Please email me at mebha at microsoft dot com

Happy to help!

Best,

Meet Bhagdev

Program Manager, Microsoft

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 03, 2015 6:55 PM

I have been having the same problem for the last few hours with a database in Northern Europe

ex = {"Database 'CompanyFile' on server 'hector' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '12AAB1B5-059C-402B-B057-436EA7FB8E92'

We use retry logic and it has been working fine for months. The database was created as V12 Preview.

We can no longer connect via our app or SSMS. According to the management portal the database is active.

• Edited by Emp Nr 852534 Wednesday, June 03, 2015 10:42 PM

I have been having the same problem for the last few hours with a database in Northern Europe

ex = {"Database 'CompanyFile' on server 'hector' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '12AAB1B5-059C-402B-B057-436EA7FB8E92'

We use retry logic and it has been working fine for months. The database was created as V12 Preview.

We can no longer connect via our app or SSMS. According to the management portal the database is active.

• Edited by Emp Nr 852534 Wednesday, June 03, 2015 10:42 PM

I have been having the same problem for the last few hours with a database in Northern Europe

ex = {"Database 'CompanyFile' on server 'hector' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '12AAB1B5-059C-402B-B057-436EA7FB8E92'

We use retry logic and it has been working fine for months. The database was created as V12 Preview.

We can no longer connect via our app or SSMS. According to the management portal the database is active.

• Edited by Emp Nr 852534 Wednesday, June 03, 2015 10:42 PM

I have been having the same problem for the last few hours with a database in Northern Europe

ex = {"Database 'CompanyFile' on server 'hector' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '12AAB1B5-059C-402B-B057-436EA7FB8E92'

We use retry logic and it has been working fine for months. The database was created as V12 Preview.

We can no longer connect via our app or SSMS. According to the management portal the database is active.

• Edited by Emp Nr 852534 Wednesday, June 03, 2015 10:42 PM

I have been having the same problem for the last few hours with a database in Northern Europe

ex = {"Database 'CompanyFile' on server 'hector' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '12AAB1B5-059C-402B-B057-436EA7FB8E92'

We use retry logic and it has been working fine for months. The database was created as V12 Preview.

We can no longer connect via our app or SSMS. According to the management portal the database is active.

• Edited by Emp Nr 852534 Wednesday, June 03, 2015 10:42 PM

I have been having the same problem for the last few hours with a database in Northern Europe

ex = {"Database 'CompanyFile' on server 'hector' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '12AAB1B5-059C-402B-B057-436EA7FB8E92'

We use retry logic and it has been working fine for months. The database was created as V12 Preview.

We can no longer connect via our app or SSMS. According to the management portal the database is active.

• Edited by Emp Nr 852534 Wednesday, June 03, 2015 10:42 PM

I have been having the same problem for the last few hours with a database in Northern Europe

ex = {"Database 'CompanyFile' on server 'hector' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '12AAB1B5-059C-402B-B057-436EA7FB8E92'

We use retry logic and it has been working fine for months. The database was created as V12 Preview.

We can no longer connect via our app or SSMS. According to the management portal the database is active.

• Edited by Emp Nr 852534 Wednesday, June 03, 2015 10:42 PM

I have been having the same problem for the last few hours with a database in Northern Europe

ex = {"Database 'CompanyFile' on server 'hector' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '12AAB1B5-059C-402B-B057-436EA7FB8E92'

We use retry logic and it has been working fine for months. The database was created as V12 Preview.

We can no longer connect via our app or SSMS. According to the management portal the database is active.

• Edited by Emp Nr 852534 Wednesday, June 03, 2015 10:42 PM

I have been having the same problem for the last few hours with a database in Northern Europe

ex = {"Database 'CompanyFile' on server 'hector' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '12AAB1B5-059C-402B-B057-436EA7FB8E92'

We use retry logic and it has been working fine for months. The database was created as V12 Preview.

We can no longer connect via our app or SSMS. According to the management portal the database is active.

• Edited by Emp Nr 852534 Wednesday, June 03, 2015 10:42 PM

Thanks.  I appreciate the response.  I've been through those  examples.  I understand the examples, however, I'm using entity framework and am not quite sure what to put this logic at.  Should this go as some override in the  SqlAzureDBConfiguration class?  If so, where.?  Where should this retry logic go?

Wally

Hi Wally,

If you are using the enterprise library, just follow the instructions on this link : https://msdn.microsoft.com/en-us/library/azure/dn961167.aspx?f=255&MSPPError=-2147217396

That should do the trick for you.

Hi Emp Nr, Can you file a support ticket so that we can take a look at it?

Thanks Bhagdev.  I'm not using the enterprise library.  I'm just using entity framework and linq on top of that.  I thought about changing to it, but I'd like to keep things as similar to what I have right now as I can.  I like to keep things really simple.  Will this be possible?

Wally

Wally, 

Have you figure out the cause of this issue?  I got the same thing 28 times(!) today.  I am also using Entity Framework and linq. 

• Edited by ksanchezssmci 7 hours 36 minutes ago

Wally, 

Have you figure out the cause of this issue?  I got the same thing 28 times(!) today.  I am also using Entity Framework and linq. 

• Edited by ksanchezssmci 7 hours 24 minutes ago

Hello, 

I just started getting this error today.  You mention submitting a ticket,  is this only if you have a support plan?

Also, what are the reasons that this would start suddenly?

Wally, 

Have you figure out the cause of this issue?  I got the same thing 28 times(!) today.  I am also using Entity Framework and linq. 

• Edited by ksanchezssmci Wednesday, June 10, 2015 11:43 PM

Wally, 

Have you figure out the cause of this issue?  I got the same thing 28 times(!) today.  I am also using Entity Framework and linq. 

• Edited by ksanchezssmci Wednesday, June 10, 2015 11:43 PM

Wally, 

Have you figure out the cause of this issue?  I got the same thing 28 times(!) today.  I am also using Entity Framework and linq. 

• Edited by ksanchezssmci Wednesday, June 10, 2015 11:43 PM

Wally, 

Have you figure out the cause of this issue?  I got the same thing 28 times(!) today.  I am also using Entity Framework and linq. 

• Edited by ksanchezssmci Wednesday, June 10, 2015 11:43 PM

Wally, 

Have you figure out the cause of this issue?  I got the same thing 28 times(!) today.  I am also using Entity Framework and linq. 

• Edited by ksanchezssmci Wednesday, June 10, 2015 11:43 PM

Wally, 

Have you figure out the cause of this issue?  I got the same thing 28 times(!) today.  I am also using Entity Framework and linq. 

• Edited by ksanchezssmci Wednesday, June 10, 2015 11:43 PM

Wally, 

Have you figure out the cause of this issue?  I got the same thing 28 times(!) today.  I am also using Entity Framework and linq. 

• Edited by ksanchezssmci Wednesday, June 10, 2015 11:43 PM

Is it possible to put the retry logic into entity framework/linq? I'm asking because the lack of a response makes me think that it is not possible. Linq and ef are supposed to be first class libraries with a first class feature set. I've done what msft says and have used them. I love the development experience. However, if the result is going to be that a network hiccup in a different region in azure, which seems to be pretty common, will interrupt the connection, then I need to reevaluate. ado.net isn't considered the tool to use any more, yet it seems to have a solution for this problem. i don't really want to add another layer of complexity into my app. Can I get this retry logic into ef/Linq?

No, I've never gotten a solution to this. I decided to circle back to see if there are any good suggestions, and haven't seen them. I'm still hoping for something.

Wally, you can put retry logic in entity framework by setting execution strategy in your DbConfiguration class, like this: 

SetExecutionStrategy(SqlProviderServices.ProviderInvariantName, () => new SqlAzureExecutionStrategy());

SqlAzureExecutionStrategy comes with entity framework and handles this error (40613) and some others.

However the connection error lasts for minutes like it has done sometimes lately, your application will still get the error. 

Wally,

Retry logic comes built-in with EF. The easiest way to tell EF to use an execution strategy is with the SetExecutionStrategy method of the DbConfiguration class:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy()); 
    } 
}

This code tells EF to use the SqlAzureExecutionStrategy when connecting to SQL Server/Azure SQL DB.

The constructor of SqlAzureExecutionStrategy can accept two parameters, MaxRetryCount and MaxDelay. MaxRetry count is the maximum number of times that the strategy will retry. The MaxDelay is a TimeSpan representing the maximum delay between retries that the execution strategy will use. 

To set the maximum number of retries to 1 and the maximum delay to 30 seconds you would execue the following:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy( 
            "System.Data.SqlClient", 
            () => new SqlAzureExecutionStrategy(1, TimeSpan.FromSeconds(30))); 
    } 
}
The SqlAzureExecutionStrategy will retry instantly the first time a transient failure occurs, but will delay longer between each retry until either the max retry limit is exceeded or the total time hits the max delay.

The execution strategies will only retry a limited number of exceptions that are usually tansient, you will still need to handle other errors as well as catching the RetryLimitExceeded exception for the case where an error is not transient or takes too long to resolve itself.

Let me know if this helps. If not we will try to figure something out. Can you also share what are some of the exceptions/error codes you are trying to handle. Just want to make sure that they are among the ones EF handles by default.

Best,

Meet

• Edited by Meet BhagdevMicrosoft employee 10 hours 34 minutes ago modificaiton

Wally,

Retry logic comes built-in with EF. The easiest way to tell EF to use an execution strategy is with the SetExecutionStrategy method of the DbConfiguration class:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy()); 
    } 
}

This code tells EF to use the SqlAzureExecutionStrategy when connecting to SQL Server/Azure SQL DB.

The constructor of SqlAzureExecutionStrategy can accept two parameters, MaxRetryCount and MaxDelay. MaxRetry count is the maximum number of times that the strategy will retry. The MaxDelay is a TimeSpan representing the maximum delay between retries that the execution strategy will use. 

To set the maximum number of retries to 1 and the maximum delay to 30 seconds you would execue the following:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy( 
            "System.Data.SqlClient", 
            () => new SqlAzureExecutionStrategy(1, TimeSpan.FromSeconds(30))); 
    } 
}
The SqlAzureExecutionStrategy will retry instantly the first time a transient failure occurs, but will delay longer between each retry until either the max retry limit is exceeded or the total time hits the max delay.

The execution strategies will only retry a limited number of exceptions that are usually tansient, you will still need to handle other errors as well as catching the RetryLimitExceeded exception for the case where an error is not transient or takes too long to resolve itself.

Let me know if this helps. If not we will try to figure something out. Can you also share what are some of the exceptions/error codes you are trying to handle. Just want to make sure that they are among the ones EF handles by default.

Best,

Meet

• Edited by Meet BhagdevMicrosoft employee 10 hours 40 minutes ago modificaiton

Wally,

Retry logic comes built-in with EF. The easiest way to tell EF to use an execution strategy is with the SetExecutionStrategy method of the DbConfiguration class:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy()); 
    } 
}

This code tells EF to use the SqlAzureExecutionStrategy when connecting to SQL Server/Azure SQL DB.

The constructor of SqlAzureExecutionStrategy can accept two parameters, MaxRetryCount and MaxDelay. MaxRetry count is the maximum number of times that the strategy will retry. The MaxDelay is a TimeSpan representing the maximum delay between retries that the execution strategy will use. 

To set the maximum number of retries to 1 and the maximum delay to 30 seconds you would execue the following:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy( 
            "System.Data.SqlClient", 
            () => new SqlAzureExecutionStrategy(1, TimeSpan.FromSeconds(30))); 
    } 
}
The SqlAzureExecutionStrategy will retry instantly the first time a transient failure occurs, but will delay longer between each retry until either the max retry limit is exceeded or the total time hits the max delay.

The execution strategies will only retry a limited number of exceptions that are usually tansient, you will still need to handle other errors as well as catching the RetryLimitExceeded exception for the case where an error is not transient or takes too long to resolve itself.

Let me know if this helps. If not we will try to figure something out. Can you also share what are some of the exceptions/error codes you are trying to handle. Just want to make sure that they are among the ones EF handles by default.

Best,

Meet

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 24, 2015 8:32 PM modificaiton
• Proposed as answer by Mish Bryant 12 hours 51 minutes ago

Wally,

Retry logic comes built-in with EF. The easiest way to tell EF to use an execution strategy is with the SetExecutionStrategy method of the DbConfiguration class:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy()); 
    } 
}

This code tells EF to use the SqlAzureExecutionStrategy when connecting to SQL Server/Azure SQL DB.

The constructor of SqlAzureExecutionStrategy can accept two parameters, MaxRetryCount and MaxDelay. MaxRetry count is the maximum number of times that the strategy will retry. The MaxDelay is a TimeSpan representing the maximum delay between retries that the execution strategy will use. 

To set the maximum number of retries to 1 and the maximum delay to 30 seconds you would execue the following:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy( 
            "System.Data.SqlClient", 
            () => new SqlAzureExecutionStrategy(1, TimeSpan.FromSeconds(30))); 
    } 
}
The SqlAzureExecutionStrategy will retry instantly the first time a transient failure occurs, but will delay longer between each retry until either the max retry limit is exceeded or the total time hits the max delay.

The execution strategies will only retry a limited number of exceptions that are usually tansient, you will still need to handle other errors as well as catching the RetryLimitExceeded exception for the case where an error is not transient or takes too long to resolve itself.

Let me know if this helps. If not we will try to figure something out. Can you also share what are some of the exceptions/error codes you are trying to handle. Just want to make sure that they are among the ones EF handles by default.

Best,

Meet

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 24, 2015 8:32 PM modificaiton
• Proposed as answer by Mish Bryant 13 hours 2 minutes ago

Wally,

Retry logic comes built-in with EF. The easiest way to tell EF to use an execution strategy is with the SetExecutionStrategy method of the DbConfiguration class:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy()); 
    } 
}

This code tells EF to use the SqlAzureExecutionStrategy when connecting to SQL Server/Azure SQL DB.

The constructor of SqlAzureExecutionStrategy can accept two parameters, MaxRetryCount and MaxDelay. MaxRetry count is the maximum number of times that the strategy will retry. The MaxDelay is a TimeSpan representing the maximum delay between retries that the execution strategy will use. 

To set the maximum number of retries to 1 and the maximum delay to 30 seconds you would execue the following:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy( 
            "System.Data.SqlClient", 
            () => new SqlAzureExecutionStrategy(1, TimeSpan.FromSeconds(30))); 
    } 
}
The SqlAzureExecutionStrategy will retry instantly the first time a transient failure occurs, but will delay longer between each retry until either the max retry limit is exceeded or the total time hits the max delay.

The execution strategies will only retry a limited number of exceptions that are usually tansient, you will still need to handle other errors as well as catching the RetryLimitExceeded exception for the case where an error is not transient or takes too long to resolve itself.

Let me know if this helps. If not we will try to figure something out. Can you also share what are some of the exceptions/error codes you are trying to handle. Just want to make sure that they are among the ones EF handles by default.

Best,

Meet

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 24, 2015 8:32 PM modificaiton
• Proposed as answer by Mish Bryant Thursday, June 25, 2015 6:16 PM
• Marked as answer by Casey KarstMicrosoft employee, Moderator 15 hours 19 minutes ago

Wally,

Retry logic comes built-in with EF. The easiest way to tell EF to use an execution strategy is with the SetExecutionStrategy method of the DbConfiguration class:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy()); 
    } 
}

This code tells EF to use the SqlAzureExecutionStrategy when connecting to SQL Server/Azure SQL DB.

The constructor of SqlAzureExecutionStrategy can accept two parameters, MaxRetryCount and MaxDelay. MaxRetry count is the maximum number of times that the strategy will retry. The MaxDelay is a TimeSpan representing the maximum delay between retries that the execution strategy will use. 

To set the maximum number of retries to 1 and the maximum delay to 30 seconds you would execue the following:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy( 
            "System.Data.SqlClient", 
            () => new SqlAzureExecutionStrategy(1, TimeSpan.FromSeconds(30))); 
    } 
}
The SqlAzureExecutionStrategy will retry instantly the first time a transient failure occurs, but will delay longer between each retry until either the max retry limit is exceeded or the total time hits the max delay.

The execution strategies will only retry a limited number of exceptions that are usually tansient, you will still need to handle other errors as well as catching the RetryLimitExceeded exception for the case where an error is not transient or takes too long to resolve itself.

Let me know if this helps. If not we will try to figure something out. Can you also share what are some of the exceptions/error codes you are trying to handle. Just want to make sure that they are among the ones EF handles by default.

Best,

Meet

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 24, 2015 8:32 PM modificaiton
• Proposed as answer by Mish Bryant Thursday, June 25, 2015 6:16 PM
• Marked as answer by Casey KarstMicrosoft employee, Moderator 15 hours 29 minutes ago

Wally,

Retry logic comes built-in with EF. The easiest way to tell EF to use an execution strategy is with the SetExecutionStrategy method of the DbConfiguration class:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy()); 
    } 
}

This code tells EF to use the SqlAzureExecutionStrategy when connecting to SQL Server/Azure SQL DB.

The constructor of SqlAzureExecutionStrategy can accept two parameters, MaxRetryCount and MaxDelay. MaxRetry count is the maximum number of times that the strategy will retry. The MaxDelay is a TimeSpan representing the maximum delay between retries that the execution strategy will use. 

To set the maximum number of retries to 1 and the maximum delay to 30 seconds you would execue the following:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy( 
            "System.Data.SqlClient", 
            () => new SqlAzureExecutionStrategy(1, TimeSpan.FromSeconds(30))); 
    } 
}
The SqlAzureExecutionStrategy will retry instantly the first time a transient failure occurs, but will delay longer between each retry until either the max retry limit is exceeded or the total time hits the max delay.

The execution strategies will only retry a limited number of exceptions that are usually tansient, you will still need to handle other errors as well as catching the RetryLimitExceeded exception for the case where an error is not transient or takes too long to resolve itself.

Let me know if this helps. If not we will try to figure something out. Can you also share what are some of the exceptions/error codes you are trying to handle. Just want to make sure that they are among the ones EF handles by default.

Best,

Meet

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 24, 2015 8:32 PM modificaiton
• Proposed as answer by Mish Bryant Thursday, June 25, 2015 6:16 PM
• Marked as answer by Casey KarstMicrosoft employee, Moderator Friday, June 26, 2015 3:48 PM

Wally,

Retry logic comes built-in with EF. The easiest way to tell EF to use an execution strategy is with the SetExecutionStrategy method of the DbConfiguration class:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy()); 
    } 
}

This code tells EF to use the SqlAzureExecutionStrategy when connecting to SQL Server/Azure SQL DB.

The constructor of SqlAzureExecutionStrategy can accept two parameters, MaxRetryCount and MaxDelay. MaxRetry count is the maximum number of times that the strategy will retry. The MaxDelay is a TimeSpan representing the maximum delay between retries that the execution strategy will use. 

To set the maximum number of retries to 1 and the maximum delay to 30 seconds you would execue the following:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy( 
            "System.Data.SqlClient", 
            () => new SqlAzureExecutionStrategy(1, TimeSpan.FromSeconds(30))); 
    } 
}
The SqlAzureExecutionStrategy will retry instantly the first time a transient failure occurs, but will delay longer between each retry until either the max retry limit is exceeded or the total time hits the max delay.

The execution strategies will only retry a limited number of exceptions that are usually tansient, you will still need to handle other errors as well as catching the RetryLimitExceeded exception for the case where an error is not transient or takes too long to resolve itself.

Let me know if this helps. If not we will try to figure something out. Can you also share what are some of the exceptions/error codes you are trying to handle. Just want to make sure that they are among the ones EF handles by default.

Best,

Meet

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 24, 2015 8:32 PM modificaiton
• Proposed as answer by Mish Bryant Thursday, June 25, 2015 6:16 PM
• Marked as answer by Casey KarstMicrosoft employee, Moderator Friday, June 26, 2015 3:48 PM

Wally,

Retry logic comes built-in with EF. The easiest way to tell EF to use an execution strategy is with the SetExecutionStrategy method of the DbConfiguration class:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy()); 
    } 
}

This code tells EF to use the SqlAzureExecutionStrategy when connecting to SQL Server/Azure SQL DB.

The constructor of SqlAzureExecutionStrategy can accept two parameters, MaxRetryCount and MaxDelay. MaxRetry count is the maximum number of times that the strategy will retry. The MaxDelay is a TimeSpan representing the maximum delay between retries that the execution strategy will use. 

To set the maximum number of retries to 1 and the maximum delay to 30 seconds you would execue the following:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy( 
            "System.Data.SqlClient", 
            () => new SqlAzureExecutionStrategy(1, TimeSpan.FromSeconds(30))); 
    } 
}
The SqlAzureExecutionStrategy will retry instantly the first time a transient failure occurs, but will delay longer between each retry until either the max retry limit is exceeded or the total time hits the max delay.

The execution strategies will only retry a limited number of exceptions that are usually tansient, you will still need to handle other errors as well as catching the RetryLimitExceeded exception for the case where an error is not transient or takes too long to resolve itself.

Let me know if this helps. If not we will try to figure something out. Can you also share what are some of the exceptions/error codes you are trying to handle. Just want to make sure that they are among the ones EF handles by default.

Best,

Meet

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 24, 2015 8:32 PM modificaiton
• Proposed as answer by Mish Bryant Thursday, June 25, 2015 6:16 PM
• Marked as answer by Casey KarstMicrosoft employee, Moderator Friday, June 26, 2015 3:48 PM

Wally,

Retry logic comes built-in with EF. The easiest way to tell EF to use an execution strategy is with the SetExecutionStrategy method of the DbConfiguration class:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy()); 
    } 
}

This code tells EF to use the SqlAzureExecutionStrategy when connecting to SQL Server/Azure SQL DB.

The constructor of SqlAzureExecutionStrategy can accept two parameters, MaxRetryCount and MaxDelay. MaxRetry count is the maximum number of times that the strategy will retry. The MaxDelay is a TimeSpan representing the maximum delay between retries that the execution strategy will use. 

To set the maximum number of retries to 1 and the maximum delay to 30 seconds you would execue the following:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy( 
            "System.Data.SqlClient", 
            () => new SqlAzureExecutionStrategy(1, TimeSpan.FromSeconds(30))); 
    } 
}
The SqlAzureExecutionStrategy will retry instantly the first time a transient failure occurs, but will delay longer between each retry until either the max retry limit is exceeded or the total time hits the max delay.

The execution strategies will only retry a limited number of exceptions that are usually tansient, you will still need to handle other errors as well as catching the RetryLimitExceeded exception for the case where an error is not transient or takes too long to resolve itself.

Let me know if this helps. If not we will try to figure something out. Can you also share what are some of the exceptions/error codes you are trying to handle. Just want to make sure that they are among the ones EF handles by default.

Best,

Meet

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 24, 2015 8:32 PM modificaiton
• Proposed as answer by Mish Bryant Thursday, June 25, 2015 6:16 PM
• Marked as answer by Casey KarstMicrosoft employee, Moderator Friday, June 26, 2015 3:48 PM

Wally,

Retry logic comes built-in with EF. The easiest way to tell EF to use an execution strategy is with the SetExecutionStrategy method of the DbConfiguration class:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy()); 
    } 
}

This code tells EF to use the SqlAzureExecutionStrategy when connecting to SQL Server/Azure SQL DB.

The constructor of SqlAzureExecutionStrategy can accept two parameters, MaxRetryCount and MaxDelay. MaxRetry count is the maximum number of times that the strategy will retry. The MaxDelay is a TimeSpan representing the maximum delay between retries that the execution strategy will use. 

To set the maximum number of retries to 1 and the maximum delay to 30 seconds you would execue the following:

public class MyConfiguration : DbConfiguration 
{ 
    public MyConfiguration() 
    { 
        SetExecutionStrategy( 
            "System.Data.SqlClient", 
            () => new SqlAzureExecutionStrategy(1, TimeSpan.FromSeconds(30))); 
    } 
}
The SqlAzureExecutionStrategy will retry instantly the first time a transient failure occurs, but will delay longer between each retry until either the max retry limit is exceeded or the total time hits the max delay.

The execution strategies will only retry a limited number of exceptions that are usually tansient, you will still need to handle other errors as well as catching the RetryLimitExceeded exception for the case where an error is not transient or takes too long to resolve itself.

Let me know if this helps. If not we will try to figure something out. Can you also share what are some of the exceptions/error codes you are trying to handle. Just want to make sure that they are among the ones EF handles by default.

Best,

Meet

• Edited by Meet BhagdevMicrosoft employee Wednesday, June 24, 2015 8:32 PM modificaiton
• Proposed as answer by Mish Bryant Thursday, June 25, 2015 6:16 PM
• Marked as answer by Casey KarstMicrosoft employee, Moderator Friday, June 26, 2015 3:48 PM