|
Derek Price
|
|
|
Group: Forum Members
Posts: 51,
Visits: 376
|
I'm glad to see we have similar development teams!  Thanks for checking into this for us.
|
|
|
|
|
Trent Taylor
|
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
Have you been able to reproduce my connection string issue?
Not yet...but it sounds like you may be trying to do some things in which it was not intended. FWIW, we deploy to hundreds of installs frequently and have yet to run into an environment this has happened. We run some pre-install tests to make sure that people are out of our software, etc. But even in house, we use the DDT to deploy while people are in all of the time...because you always here someone yelling from the other room, "I was in the middle of saving something!"
|
|
|
|
|
Derek Price
|
|
|
Group: Forum Members
Posts: 51,
Visits: 376
|
We actually don't really need to use the connection string. As I hinted to in one of the other posts, we originally saw this problem actually supplying explicit parameters and not a connection string over the network. The problem I had was trying to provide a reproducible case for you to test. It turned out that when I used a connection string on my local machine, it exhibited the locking database issue that was very reproducible. Our actual need is much more complicated. We can get into that later as it involves a VPN connection, a web server running StrataFrame Enterprise Server, a separate database server, all within a private network, with a DMZ thrown in for good measure. I figure if you can help us solve the locking database with the local connection string example, we can provide much more information in case our complicated deploy doesn't work. Have you been able to reproduce my connection string issue?
Thanks,
Derek
|
|
|
|
|
Trent Taylor
|
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
Got it...I still have some questions. Why is it that you want to use a connection string instead of providing the credentials? When you do this, it takes control away from SMO (which is what we use) in regards to the connection to the database. It may require some T-SQL code in this scenario as well as some server side settings to be set. We constantly deploy databases with connections using the designed mechanism of the discrete data being provided to the Database Migrator class...without issue. I am just trying to understand your logic here. If you already have a connection string and just want to parse it out into discrete pieces, this is actually very easy using the SqlConnectionStringBuilder class. Just curious on this point. Thanks.
|
|
|
|
|
Derek Price
|
|
|
Group: Forum Members
Posts: 51,
Visits: 376
|
I've emailed the solution and package file.
Thanks,
Derek
|
|
|
|
|
Trent Taylor
|
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
Can you send me a sample of how you are reproducing this? I have not been able to reproduce. Thanks.
|
|
|
|
|
Derek Price
|
|
|
Group: Forum Members
Posts: 51,
Visits: 376
|
I get this right at the beginning just after calling: _databaseMigrator.DeployMetaData(PackagePath, FrameworkPassword); Here's the log file generated: 3/6/2009 10:48:24 AM -> *** Starting Deployment...
3/6/2009 10:48:24 AM -> Package Path = P:\PackagePath\MyPackage.pkg
3/6/2009 10:48:24 AM -> Connection String = server=MyServer;Integrated Security=SSPI;database=MyDatabase;
3/6/2009 10:48:24 AM -> Windows Authen. = True
3/6/2009 10:48:25 AM -> Checking SQL Connection...
3/6/2009 10:48:25 AM -> SQL Connection is valid
3/6/2009 10:48:25 AM -> Executing Pre-Deployment Scripts, Executing Pre-Deployment Scripts
3/6/2009 10:48:46 AM ->
*** Error Executing Script, SqlException
Cannot drop database "MyDatabase" because it is currently in use.
Source : .Net SqlClient Data Provider
Stack Trace:
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async)
at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator.ExecuteProfileScripts(DataView scriptsToExecute)
***
3/6/2009 10:48:46 AM ->
*** Error Deploying Meta-Data, ThreadAbortException
Thread was being aborted.
Source : MicroFour StrataFrame DBEngine
Stack Trace:
at MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator.ExecuteProfileScripts(DataView scriptsToExecute)
at MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator.ExecutePreProfileScripts()
at MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator.EnsureDatabases()
at MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator.DeployMetaDataThread()
***
|
|
|
|
|
Trent Taylor
|
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
At what point do you get this anyway? Before deployment, after, etc.?
|
|
|
|
|
Derek Price
|
|
|
Group: Forum Members
Posts: 51,
Visits: 376
|
I tried your updated connection string and it made no difference. I still got the database-in-use error. I know for a fact that there is no other connection to the database before running the app. If I run the app with explicit SQL server and windows authentication it works fine.
The problem is that we were running this on a network using explicit credentials and were seeing this locking issue and there were definitely no other connections. However, if I run it with explicit SQL server, username, and password, it works fine on my local machine.
I specifically chose the connection string method as it was a reproducible on my local machine that exhibited the locking database issue. Also, I think you're catching the general Exception in your source which hid some errors like missing SQL assemblies.
I would be happy to zip up the small (16K) solution and see if you can reproduce this issue. I'm not sure why it locks the database using a connection string, but doesn't when using explicit credentials.
Thanks,
Derek
|
|
|
|
|
Trent Taylor
|
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
Well, SQL Server is is not dropping the connection. This is a bit strange in the way that it is manifesting itself. But you will wan to ensure that all connections get closed. First of all, you will be better off supplying the authentication credentials to the DatabaseMigrator versus the connection string as it is a bit more reliable in most environments. ALso, your connection string doesn't look quite right: Data Source=MyServer;Initial Catalog=MyDatabase;Integrated Security=True"; should be more like server=MyServer=Integrated Security=SSPI;database=MyDatabase;
|
|
|
|