Storing and accessing connection strings inside a migration project

Is there any way of explicitly stating which connection string I want to use for all migration.cs files inside a project? Or should I just write something myself?

Also is there any reason I have to restart VS 2008 after every time I open the Run Migrations dialog and exit it?

After opening and exiting the dialog once it doesn't open again when I click on the Run Migrations menu item. It's a little frustrating.

Lastly, is there anywhere I can find an example of the connectionString you're looking for, I can't currently use the one defined in our web.config. I've got it down to User ID="username" throwing an error?

Thanks again, Edward

A migration project does not define its own connection string, because a migration has to be runnable against many databases (dev, QA, staging, production, etc.) all of which will have different host names, credentials, etc. If you run migrations from VS then we remember the connection string from session to session. If you host migrations in your own app then you pass the connection string in when you call Migrator.Migrate. In all cases, the same connection string is used for each migration in the project.

Connection strings are standard database connection strings in the normal format for your database. Your normal connection string from your config file or the model Properties grid should work, provided you are using the same database provider and the user account has suitable permissions. What error do you see? What database are you using? What does your connection string look like?

You shouldn't need to restart VS2008 between instances of Run Migrations. Not sure what could cause the behaviour you're seeing -- we'll investigate -- thanks for reporting this!

We've managed to fix the connection string, so thanks for your help on that :).

I tried to delete some of the migrations from the project, but that seems to have made the project not build anymore.(All the deleted files have appeared again with yellow signs with exclaimation marks)

What is the safe way to delete a migration?

And could we please show the Migrations menu option when I am in a Migrations project? It would save me a bunch of time. Thanks :)

The yellow sign is Visual Studio telling you that the file is part of the project, but is missing on disk. You may have deleted the file through Windows Explorer but not removed it in Visual Studio. (Or you might have committed the file deletion to source control, but not committed the .csproj with the file reference removed -- that sort of thing.) Right-click the file and choose Remove.

For migrations, however, deleting the .cs file alone is not enough because that's not enough to tell LightSpeed to go back to an earlier baseline for calculating the next migration. You must also go into the Models folder of the migration project and delete the associated .lsmcheckpoint files. (If you leave the .lsmcheckpoint files, it shouldn't stop the project building, but it may confuse LightSpeed when you come to recreate the migrations from the .lsmodel.)

Thanks for the suggestion to show the Migrations menu option when you're in a migrations project. That sounds like a really useful enhancement. I'll need to take a look at how feasible it is, but if it's not too hard, it definitely sounds worth doing. Thanks!

On the Run Migrations window not opening, maybe it could be slow database access? When I open the window for the first time VS2008 hangs for a few seconds, then it opens. When I open it again a few seconds later, nothing happens. After waiting 5 or so minutes, and continually trying to open it, it sometimes opens again. After restarting VS2008, it will start as if it was the first time(straight away). Is there anything I else I can do to help you find and fix this migration-breaking bug?

Slow database access could explain the 'hangs for a few seconds' the first time you open the window, as the window needs to query the database to find out what the current version is. I'm not sure it would explain the subsequent problems though. Have you tried it against a fast local database just to see if it makes a difference?

Does the problem occur if you just opened and closed the window without doing anything, or only if you ran a migration the first time the window was open?

When I close it without doing anything, it doesn't open again. After generating SQL and closing it, it still doesn't open again. I am running an older version of Lightspeed, could this be causing the problem?

I am getting "ConnectionString not initilized" now when I try to generateSQL, does this mean the ConnectionString I entered is wrong?

Accessing a local database means it doesn't hang, but it still doesn't open again after quitting.

Okay, I'm afraid I'm pretty much stumped by this, though it is worth trying a more recent version of LightSpeed just in case.

One more question: while you're waiting for the migrations window to open, is the CPU busy, or is it idle? Is Visual Studio responsive, or is it hung?

I'm adding some logging to the next nightly build which might help us track down where the hang is occurring. You'll need to run VS2008 with the /log switch: to do this, open a VS2008 command prompt and enter devenv /log at the command prompt. You'll find the log file at %AppData% > Roaming > Microsoft > Visual Studio > 9.0 > ActivityLog.xml -- if you could email it to us or attach it to a forum post then that would be awesome. Thanks!

"Connection string not initialised" usually means that no connection string has been entered at all, but the connection string isn't needed if you're generating SQL to a Visual Studio window -- only the database type. Again, I've tried to reproduce this but haven't been able to -- we do check for this case and either disable controls or display suitable messages, and I'm not able to generate the raw connection string error.

Is it possible for you to capture a video of what you're doing and where the connection string error is occurring, using Jing (http://www.techsmith.com/jing.html) or something like that? That could really help to nail down the problem. Thanks!

Absoloutly, I will get to recording the errors for you. Where do I find out what version of Lightspeed we are currently running so I can tell you that as well?

Thanks! To find the version of LightSpeed, go into the installation directory, Bin subdirectory, right-click the LightSpeed DLL, choose Properties, and check the Version tab.

We're using 3.1.2089.15080.

I've put in a request to renew our license which has been granted, so I will update as soon as that goes through and check if the error still exists.

Thanks for your help.