Question

I’m developing an Azure/MVC4 application using Visual Studio Web Developer 2010 Express, on a laptop tied to an Active Directory, and sync the project between two PCs. The second PC has got Visual Studio 2010 Professional and is not on an Active Directory.

On the second PC everything works fine, including publishing to Azure. On the laptop, I cannot connect to the local SQL Server Express database. I’m using Windows Authentication.

Here’s my connection string:

<add name="DefaultConnection" 
     connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=aspnet-HomeNetworking-20121017194204;Integrated Security=SSPI;" 
     providerName="System.Data.SqlClient" />

However when trying to connect to the application, I’m getting an error (I changed the domain and login):

Cannot open database “aspnet-HomeNetworking-20121017194204” requested by the login. The login failed. Login failed for user
‘DOMAINNAME\UserName’.

Even if I switch to SQL Authentication and explicitly provide the “sa” login and password, the connection is refused. I can connect just fine using the SQL Server Management Studio, using either Windows or SQL Authentication, so the database rights seem okay.

I have read the other questions about similar problems but none of them seem to fix my issue.

I use FluentNHibernate, and here’s the CreateSessionFactory code excerpt:

public static ISessionFactory CreateSessionFactory()
        {
            return Fluently.Configure()
                .Database(MsSqlConfiguration.MsSql2008
                    .ConnectionString(c => c.FromConnectionStringWithKey("DefaultConnection"))
                    .ShowSql())
                    .Cache(c => c.UseQueryCache().ProviderClass<HashtableCacheProvider>())
                .Mappings(m =>m.FluentMappings.AddFromAssemblyOf<Benchmark>())                
                .ExposeConfiguration(cfg => new SchemaUpdate(cfg).Execute(false, true))
                .BuildSessionFactory();
        }

Again, please note that this works fine on the non-Domain enabled PC, as well as on Windows Azure (where the connection string uses Azure SQL instead).

Answer 1

The solution (or rather the workaround) was to set the ownership of the database to the Windows credentials – even though it could access it from the permissions settings, only doing this operation solved the issue.