It seems like recently the feature of including static data during the build process was added. However there seems to be a bug with it and I've opened a ticket for it. Also, some of us may not want to always push our static data. In our case we have our base data for a new environment and we want VSTS Online to have an option to TURN OFF static data during the DLM Build process in VSTS Online.

Please make it possible to specify a custom schema name when publishing a build to DLM Dashboard. The current implementation only supports using the nuget package version which has restrictive formatting rules, so for example it does not work for apps which use a four-part version number.

Static data should be deployed in commit order rather than at the end of the deployment script.

It is currently impossible to write a migration script which depends on static data as the static data will not exist at the point the migration script runs. The migration script can't insert the static data it needs as deployment will then fail later when inserting the new static data which now already exists.

I need to execute Use-DlmDatabaseRelease against hundreds of databases per server (times a dozen or more servers). None of the Powershell multithreading approaches I've found matches the speed of SQL Multiscript. It would be a huge performance boost to be able to feed a Use-... statement or a generic script block to a Multiscript cmdlet for swift parallel handling.

Having licenced SQL CI coupled and individual SQL Source Control licences all with maintenance on advice of Redgate sales we've been merrily using this until now. Needing to buy additional licences for SQL Source Control we are now hit with an eye watering quote to have to upgrade from SQL CI to DLM automation.

Apart from the fact that the product recommended to us originally has been superseded twice with no contact from Redgate, there has been a sneaky shift to a per user licence fro DLM automation. So what was an expensive server licenced product in SQL CI has now become a per developer licenced product in DLM Automation. Any developer who contributes to SQL changes deployed through DLM automation now requires a licence. The only way to obtain a licence is to buy a full SQL Toolbelt.

The result of this means our initial outlay of the licences for SQL Source Control and SQL CI now has to be written off, the SQL Source control licences are worthless as we are effectively re licencing the same products at a substantially higher cost and what do we get out of it ? Nothing apart from a clear conscience.

This hasn't been thought through at all and I'm sorry to say it reeks of corporate greed.

I'd seriously question how many existing customers are correctly licenced.

Having licenced SQL CI coupled and individual SQL Source Control licences all with maintenance on advice of Redgate sales we've been merrily using this until now. Needing to buy additional licences for SQL Source Control we are now hit with an eye watering quote to have to upgrade from SQL CI to DLM automation.

Apart from the fact that the product recommended to us originally has been superseded twice with no contact from Redgate, there has been a sneaky shift to a per user licence fro…

"DLM Automation works with your CI server and release management system, so you test, build, and release your database alongside your application code." Unfortunately, DLM only allows for the release of _updates_ to existing databases -- suppose the target database doesn't yet exist? Deploying a NuGet package ought to allow for the possibility of initializing a new database.

It would be good if you could skip delete operations when deploying database changes automatically. This means if we update our application code and database changes then old versions of the application code can continue to use the old database functionality.

Given that no GUI is required with Release and dotnet core is out, has this option been considered? Most deployment tools are Linux based and Octopus is limited in usefulness, or at least our application has outgrown it.

When first starting to use SQL Release, it's likely that the target database may have a few syntax errors in it. For example, it could have a sproc that references a table that doesn't exist. Alternatively, the TempDB that SQL Release is using might not support a feature that the target database uses, or the real SQL Database might not support a feature that the target database is using. In any of these cases, the error returned by New-DatabaseRelease is very unhelpful:

The only way that I've found to actually fix these issues is to run SQL Profiler against the database that is being used for the temp Database and capture the trace of what SQL Compare is trying to do and what errors SQL Server returned.

The error diagnostics in this case need to be improved.

When first starting to use SQL Release, it's likely that the target database may have a few syntax errors in it. For example, it could have a sproc that references a table that doesn't exist. Alternatively, the TempDB that SQL Release is using might not support a feature that the target database uses, or the real SQL Database might not support a feature that the target database is using. In any of these cases, the error returned by New-DatabaseRelease is very unhelpful:

This is non-trivial as we currently use static data through SQL Compare within DLMA, which does not have the same option range as SQL Data Compare.

We do now ignore timestamp columns in static data tables as of DLMA 2.0.8, so timestamp columns should no longer block other static data from deployment – please email Support if this is still not working for you.

Say we have scenarios where we have client machine configuration stored against machine names. When we deploy to DEV environment, these machines are different to TEST and we need a way to reseed the configuration data for the specific environment.

Having first class support for PreDeploy / PostDeploy scripts which could then be named using Environments (A.DEV.sql, A.TEST.sql) would be a nice feature - Especially if coupled with SQL Source Control.