Question

I must be missing something pretty basic.

I’m working on a legacy project, and I’m trying to bring
FluentMigrator into the mix cause I’ve got some interesting database
changes and data migrations coming up that I think will be made much
easier by using this tool.

For the initial migration, I just want to bring the database up to the
current production version, as-is. To simplify the initial migration,
I scripted out my SQL Server 2008 database, and the migration executes
the scripted commands as a series of SQL commands.

To test it out, I create an entirely empty database, and try to run it
from command line using this:

> migrate -a "C:\My\Project\Path\bin\debug\Rds.MyProjName.DBMigrations.dll" 
-db SqlServer2008 -conn "Data Source=.\SQLEXPRESS2008;Initial Catalog=myNewDbName;
Integrated Security=SSPI" -version=20100901000000

The version specified is the timestamp on the first migration class’s
Migration attribute.

At the command line, everything appears to run fine – the the entire
script zooms by, and it ends with:

-- CreateProductionDbCircaSep2010: migrated

However, when I take a look at the database, it is still empty.
Absolutely nothing is in there. My Up method looks like this:

public override void Up()
{
    var cmds = LoadEmbeddedResources
        .GetEmbeddedResource("scripted_db_2010-09-01.sql")
        .AsString()
        .ParseCommands();

    foreach (var c in cmds) {
        Execute.Sql(c);
    }

    CreateReferenceData();
}

(FYI, I’m parsing the script instead of running it as-is because I
started by using Migrator.Net before discovering it was dead, and this
was already set up.)

Can anyone give me a hand? It almost appears like a transaction isn’t
committing, or some command-line option to have the migration do a dry-
run is turned on, but I don’t see it…

EDIT:Additional things I’ve tried

To confirm that the connection string was using the database I expect it to, I renamed the database and afterwards got a login error, as expected.

For further tests, I cut down the length of the script, and tried executing it using

public override void Up()
{
    Execute.Script(@"..\Resources\test.sql"); 
}

instead of command-by-command, but I get the same results. Here is the output on that test (note, I edited the pathes and such):

C:\My\Project\Path\FluentMigrator.Net\ >migrate -a "C:\My\Project\Path\bin\debug
\My.Project.DBMigrations.dll" -db SqlServer2008 -conn "Data Source=.\SQLEXPRESS2
008;Initial Catalog=myNewDbName;Integrated Security=SSPI" -version=2010090100000
0
Using Database SqlServer2008 and Connection String Data Source=.\SQLEXPRESS2008;
Initial Catalog=myNewDbName;Integrated Security=SSPI
-- VersionMigration: migrating ===============================================

-- CreateTable VersionInfo
-- VersionMigration: migrated
-- CreateProductionDbCircaSep2010: migrating =================================

-- ExecuteSqlScript C:\My\Project\Path\FluentMigrator.Net\..\Resources\test.sql
-- CreateProductionDbCircaSep2010: migrated

Yet no tables in the database – there isn’t even the expected VersionInfo table.

Answer 1

After some investigation and testing with both version 0.8 and 1.0, it appears this is a bug in FluentMigrator.Net related to the migration runner’s transaction management – if you run a migration with a specific version number, the transaction’s commit never gets called; if you don’t specify a version number, it’s fine.

EDIT:

I have since submitted a patch to the project which was accepted. This is no longer a problem.