[RESOLVED] Best practice for deploying a Db with new application

[cory_jackson]

I have a simple Db WinForm application that I designed with Entity Framework Db first. In a few days I'll need to create an installer. This software will be distributed to only a couple machines.

1. What is the best practice to create the Db on the client workstation?
2. Is it something that should be done in the application or the installer? I'm guessing the application.
3. What if the Db schema changes later? Is there a way to update in later versions of the application/installer?
4. Would it be easier to manually create the Db? If so is there a simple way to export the schema or whatever in SSMS from one machine to another?

At the moment my best plan is to use the backup feature in SSMS.

[PlausiblyDamp]

If you are already using the Entity Framework have you considered Code First Migrations https://msdn.microsoft.com/en-us/lib...v=vs.113).aspx they are designed to help with these kind of issues.

[cory_jackson]

But I designed it Db first. Can I still use this?

[PlausiblyDamp]

According to https://msdn.microsoft.com/en-us/lib...v=vs.113).aspx it looks like you should be able to.

[cory_jackson]

OK. I'll check into it. Thank you.

[FunkyDexter]

Code First Migrations are designed for a Code First Approach. They really don't play well with a Database First approach. That blog is isn't showing you how to use Code First Migrations to do ongoing development. Rather it's showing you how you can take a database, create a model from it and then use that model in a Code First approach to create a new (copy) database for deployment. That's great for a single deployment but would be a nightmare for ongoing development. And realistically, if you just want a single deployment you can just use the "Script Database As" option in SSMS. Why jump through an extra bunch of hoops?

There are a bunch of tools for rolling out DB changes that don't rely on Code First. The company I'm working for is using DBUp which is free open source and the devs seem pretty happy with it. You should be aware, though, that it requires you to script your changes so you won't be able to make changes in the SSMS GUI - personally I dislike that restriction.

I gather TFS now has database change tracking in and integrates into SSMS. That would seem like a good option to explore, particularly as there are free community editions available. And I've heard that RedGate's offering is excellent although that would require you to splash some cash.

[cory_jackson]

I'm happy you chimed in on this. I was going to start into this today. I have much to do in a short period of time so for now I'm just going to do the script method. And now there is a chance things will change. Thanks much.