9

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.
ChrisF
  • 134,786
  • 31
  • 255
  • 325
  • I am no SQL server expert but I would try removing the "persist security info" part and see whether it helps... another point: does "application" contain any spaces or similar ? – Yahia Jan 30 '12 at 14:20
  • @Yahia - No spaces in "application". "Persist Security Info" needs to be true to get the username and password back [Source](http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx) – ChrisF Jan 30 '12 at 14:24
  • You did configure the "application" in the deployed db? – H H Jan 30 '12 at 14:51
  • @HenkHolterman - Can you elaborate. At the moment I'm just picking up the pieces of something that's just broken. The quick solution is to remove "Application Name" from the connection string, but I need to know why it's breaking so we can put it back. – ChrisF Jan 30 '12 at 14:53
  • Just for the heck of it, create a test connection string using `SqlConnectionStringBuilder(connectionString)` and set the app name from there. See if that works. Maybe you have some stupid formatting or invalid character error in there. Also, have you tried different application names? I'm no expert in SQL DBs but if it's shared maybe some other application is already connecting with that App name. Do not know if that could be a problem. – InBetween Jan 30 '12 at 15:04
  • @InBetween - yep, tried different application names - same result. I thought about the invalid characters too, but that doesn't seem to be the case. – ChrisF Jan 30 '12 at 15:09
  • An 'Application Name' is an entry that you set _before_ adding users/roles with the aspnet config tool. You could also look in the (aspnet) provider db, the default appname is `/`. – H H Jan 30 '12 at 15:10
  • @HenkHolterman - Ah. The application name was added to *this* connection string so we could track which tenant was making which calls. There's only one application. I see that this could be an issue. I need to talk to the guys who added this, but they're in a different time zone. – ChrisF Jan 30 '12 at 15:13
  • Chris, all of a sudden I'm not sure this is the _same_ application-name, but worth checking out. – H H Jan 30 '12 at 15:15
  • As a best practice according to Microsoft you should always set include `persist security info = false`. Which makes one wonder why it exists in the first place as an attribute. – Doug Chamberlain Jan 31 '12 at 18:41

2 Answers2

1

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.

ChrisF
  • 134,786
  • 31
  • 255
  • 325
0

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.

Check webserver config and that the database is installed correctly.

looks like webserver config / db installion to me.

PhilW
  • 410
  • 4
  • 11
  • That's the conclusion we're coming to too. However, nothing's turned up yet. – ChrisF Jan 31 '12 at 20:34
  • @ChrisF Check (and compare to working webserver) which database and schema the user is connecting to and the user mapping in sql server. It appears the connection is being established to a database that does not have GetUserSecurityConfig. Try 'Initial Catalog=schema.database' to confirm where it is connecting to. – PhilW Feb 01 '12 at 08:19