Revisit the sp_releaseapplock for SQL Server connections

Evolve migrate with SQL Server throws the following error during build and run time:

Cannot release the application lock (Database Principal: ‘public’, Resource: ‘Evolve’) because it is not currently held. Sql query: sp_releaseapplock Cannot release the application lock (Database Principal: ‘public’, Resource: ‘Evolve’) because it is not currently held. at Evolve.WrappedConnectionEx.Execute[T](WrappedConnection wrappedConnection, String sql, Func2 query, Action1 setupDbCommand) at Evolve.WrappedConnectionEx.ExecuteDbCommand[T](WrappedConnection wrappedConnection, String sql, Action1 setupDbCommand, Func2 query) at Evolve.Dialect.SQLServer.SQLServerDatabase.ReleaseApplicationLock() at Evolve.Evolve.InternalExecuteCommand(Action`1 commandAction) at Evolve.Evolve.Migrate() at Evolve.Evolve.ExecuteCommand() at Evolve.MsBuild.EvolveBoot.Execute()

This is happening in SQL Server 2012

[lecaillon]

Thanks a lot @sergiu-svinarciuc ! That’s a serious lead. I think you’re right. And it explains why my current SQL Server tests work, because I do not change of database in my scripts V3_1 and V_3_1_1. I use the fully qualified table name to create and insert data in the new created database.

I will investigate in next days what we can do about it. And again your proposal seems legit. I just want to try to change database in a migration configured with the option : EnableClusterMode = false Consequenses will be no node synchronization at migration time (no database lock). But for some scenario it won’t be an issue.

I’ll keep you in touch Sergiu. Thanks again

[sergiu-svinarciuc]

Hey @lecaillon , first of all thank you so much for a great tool!

The root cause of the issues above, most probably, is the usage of “use [database]” statement, specifically when this one is not consistent with the target DB provided in the connection string. In such case, when Evolve is done with applying the patch, it tries to release the lock in a different context because of the “use” statement.

There is also a nasty side effect. Evolve reports back in console that the patch has been applied successfully (and the changes are actually applied) instead of doing a rollback (which I believe it can’t do because of the switched context again). Also, the patch is not registered in the changelog table.

Would it make sense to add a safety-net and fail the migration if the patch contains a “use” statement?

Happy to contribute in any ways, let me know your thoughts.