Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why does this database connection fail when "Application Name=application" is in the connection string?

We're writing a multi-tenanted Silverlight application. The user logs in using Windows Forms authentication and we pull the connection string for that user from a table. The string was of the form:

Data Source=1.2.3.4; Initial Catalog=database; Persist Security Info=True; User ID=######; Password=##########

This was working fine. We then decided that setting the application name, for reasons outlined here would be a good idea:

Data Source=1.2.3.4; Initial Catalog=database; Application Name=application; Persist Security Info=True; User ID=######; Password=##########

However, now the connection isn't being made so we're getting errors. This is only failing on the deployed site. Running via Visual Studio is apparently unaffected. There have been no changes to the code that makes the connection. I'm willing to believe that there should be changes, but I haven't been able to work out what they should be.

The connection is being created like this:

public class OurDataContext : DataContext
{
    public OurDataContext()
        : base(SessionCache.OurConnectionString)
    {
        ....
    }
 }

SessionCache.OurConnectionString is the string as read from the database.

UPDATE

The change to the connection string may be a red herring. We only get this failure on one web server (the one I don't have direct access to). Adding the property to the database referenced by another web server (that I do have access to) doesn't reproduce the problem. This is leading me to the conclusion that the error is somewhere else. However, I'm still no nearer to solving this.

The actual error is an exception:

An exception of type 'System.ServiceModel.DomainServices.Client.DomainOperationException' occurred and was caught.
------------------------------------------------------------------------------------------------------------------
01/31/2012 14:18:53  
Type : System.ServiceModel.DomainServices.Client.DomainOperationException, System.ServiceModel.DomainServices.Client, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Message : Load operation failed for query 'GetUserSecurityConfig'. The remote server returned an error: NotFound.
Status : ServerError
ErrorCode : 0
Data : System.Collections.ListDictionaryInternal
Stack Trace : The stack trace is unavailable.

All the research I've done today on this returns some fairly basic things that shouldn't have changed:

  • System.ComponentModel.DataAnnotations, System.ServiceModel.DomainServices.EntityFramework, System.ServiceModel.DomainServices.Hosting and System.ServiceModel.DomainServices.Server not being copied to the \bin directory. I've checked and they are.
  • Errors connecting to the database server. I don't think this is the case as the forms authentication works. It is a different database on the server, but the credentials are the same.
like image 237
ChrisF Avatar asked Jan 30 '12 14:01

ChrisF


People also ask

What is database connection string name?

Connection String Name property specifies the name of the named connection string that the SQL Workflow Instance Store should use to connect to the persistence database. This parameter is an optional parameter.

How do I find the connection string name in SQL Server?

Right-click on your connection and select "Properties". You will get the Properties window for your connection. Find the "Connection String" property and select the "connection string". So now your connection string is in your hands; you can use it anywhere you want.


1 Answers

The problem turned out to be due to the version of RIA Services installed on the server.

We'd recently changed the projects to include RIA Services via the NuGet package manager and this server already had RIA Services for VS2010 installed. When we sorted that out everything sprang back to life.

It's not clear why it took so long for this problem to manifest itself though.

like image 171
ChrisF Avatar answered Sep 20 '22 06:09

ChrisF