CODEWITHSUNDEEP
azureentity-framework-5azure-sql-database
jabberwik
jabberwik

Reputation: 403

Azure Worker can't connect to SQL; other Roles in the same Service can

I'm connecting from Azure Cloud Services to a SQL Azure database. Three out of four worker roles can connect and interact with the DB with no issues. The fourth, for an unknown reason, throws this exception on my first interaction with a DbSet:

System.Data.ProviderIncompatibleException: An error occurred while getting
provider information from the database. This can be caused by Entity Framework
using an incorrect connection string. Check the inner exceptions for details and
ensure that the connection string is correct.
--->    System.Data.ProviderIncompatibleException: The provider did not return a 
ProviderManifestToken string.
---> System.Data.SqlClient.SqlException: A network-related or instance-specific
error occurred while establishing a connection to SQL Server. The server was not
found or was not accessible. Verify that the instance name is correct and that
SQL Server is configured to allow remote connections. (provider: Named Pipes
Provider, error: 40 - Could not open a connection to SQL Server)
---> System.ComponentModel.Win32Exception: The system cannot find the file
specified

All four roles are using an identical connection string (from the Service Configuration), using the Entity Framework 5 DbContext from the same assembly.

Here's the connection string:

Server=tcp:aaa.database.windows.net,1433;Database=AppName;User ID=appusername@aaa;Password=999;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;

I do not receive the error when running on the dev fabric. I have tried re-imaging the deployment. SSMS connects just fine.

What else could be different on this fourth worker that would cause such an error?

Upvotes: 3

Views: 1191

Answers (3)

Woland
Woland

Reputation: 2919

If it is related to TFS Build issues, then I had the same issue with configuration files being overwritten when multiple worker roles are built, in my case it was resolved using /m:1 argument passed to msbuild.exe. More details can be found here: http://virtocommerce.blogspot.com/2013/05/building-and-publishing-azure-solution.html

Upvotes: 0

jabberwik
jabberwik

Reputation: 403

So my initial diagnosis was a little incorrect. It was not grabbing the connection string from the Service Configuration like I thought. It was coming from app.config.

The problem turned out to be related to Continuous Deployment from TFS. The default build/deploy script doesn't pay enough attention to Content files, for example, app.config! It was giving the same copy to all four workers, rather than keeping their packages segregated. This is a pretty big gotcha!

I did not find a solution or workaround; altering WWF XAMLs is not something I know how to do. I just made doubly sure that I was only getting settings from the Service Configuration (in this case, setting it for NLog at runtime).

Upvotes: 1

Fabrizio Accatino
Fabrizio Accatino

Reputation: 2292

In the past I've seen strange behaviour like yours. A VM connected to sql azure and another can't. The issue was the IP of the VM assigned by Azure. On Sql Azure you have enabled "allowed services --> WINDOWS AZURE SERVICES --> YES". But some ip addresses (too new, I suppose) are not recognised by Sql Azure as a "Azure Services". Solution: wait for IP update (days?) or add on sql azure an explicit firewall rule for your IP not working.
But I'm not sure if it's the same issue you have.

Upvotes: 0

Related Questions