Hi,

I've always used database first and Redgate to migrate db changes. But i watched the video at https://www.microsoft.com/en-us/sql-server/developer-get-started/sql-devops/ and thought it looked quite promising, what he calls "state based database development" where a Visual Studio database project contains the source code of the database - a bunch of "Create" statements essentially. Compatible with LLBLGen with db first, 1 make your changes to the database project, 2 publish to the database, 3 then update the LLBLGen model. No problem, but it would be cool if you somehow combine 1 and 3 by using model first and have LLBLGen update the database project instead of creating the migration scripts. Just a thought.

Updating database schemas is a delegate matter, and a lot of teams don't want a tool to do that, e.g. they want to test it first, see the scripts and what it does, integrate it in bigger scripts that are used to adjust production databases etc. Additionally to that, some changes need manual intervention as e.g. sql server doesn't offer a way to do the action in a script (for instance you need to create a new table, copy over the data, then drop the old table, but that requires changing FK constraints)

That's why we generate SQL scripts. In v5.7 (now in beta) we offer to open the generated script in the new sql editor in the designer, which allows you to execute it right away if you want to. So it's exporting DDL SQL changes, clicking a button, run the script and done.

In the designer we have a parallel pipeline which is designed to start jobs in the background, like what we have now with automatic code generation, and in the future we want to extend this further, where you just edit your model and everything else, including sync, ddl sql export, running of the script etc. is done in the background. However in practice this turned out to be harder than it sounds as e.g. the situation where an error occurs or the user wants to roll back a change, gives a problem that's not always solvable.

So we do have plans for that, but we also know (through prototyping) we might not go as far as running the ddl sql scripts automatically, as that's something we want to leave to the user as much as possible.

Agree different people have different preferences. I've used Redgate up till now, but it doesn't scale well price wise as the team grows and its CD offering is more expensive, whereas the database project CD offering is free. And its the CD that I really want.

It does all that drop and recreate, show the migration script, etc stuff that you mention by the way.

One of the advantages over migration based is that if you go on holiday for 2 weeks, and there's been 5 commits to the database, then you need to run the 5 migration scripts in order, whereas with state based it's a single operation.

I can still use LLBLGen with state based, and I will because I love LLBLGen.

Have a good one and stay safe