sql-serverasp.net-membershipnanttarantino

Creating ASP.NET Membership Tables Using Tarantino Database Management


I'm introducing Tarantino Database Management into a project, which has a brand new database schema. The only change (located in 0001_InitialSchema.sql) is the creation of the tables used in ASP.NET Membership. I generated the tables using aspnet_regsql.exe and then scripted them as CREATE TO scripts, then combined them into my single Tarantino sql file.

Upon running my NAnt build script, the drop database command chokes when trying to drop all connections from the database it's trying to drop.

Dropping connections for database DBName

[call] An exception occurred while executing a Transact-SQL statement or batch.

[call] Only user processes can be killed.

This causes the following create database step to fail since the database still exists, and no new updates will be applied:

ManageSqlDatabase:

Create DBName on localhost using scripts from path\to\source\src\Database

BUILD FAILED - 1 non-fatal error(s), 0 warning(s)

INTERNAL ERROR

Microsoft.SqlServer.Management.Common.ExecutionFailureException: An exception occurred while executing a Transact-SQL statement or batch. ---> System.Data.SqlClient.SqlException: Database 'DBName' already exists. Choose a different database name.

Some system process always remains attached to the database well after the script has run. I've tried running this on different machines and the same problem exists. I've also tried running a different Tarantino project, and it runs flawlessly every time. I even created a dummy update file (which added tables Foo, Bar, etc) which also ran without issues. The problem seems to stem from the CREATE TABLE scripts for the ASP.NET Membership tables.

You can find a copy of the SQL update script run at PasteBin (separated from post due to its length).


Solution

  • That would be a bug in Tarantino aparently. If you look into DropConnections.sql you'll see that the author has fallen for the old myth that any session above 50 is an user session. The correct way to identify user sessions (and thus KILL-able sessions) is to check the is_user_process column in sys.dm_exec_sessions.