Comments
Sort by recent activity
Found it. "Comparison options" is not a title in the setup tab of SQL Source Control. You can click on it to get to the options. / comments
Found it. "Comparison options" is not a title in the setup tab of SQL Source Control. You can click on it to get to the options.
Sergio, from what I understand, that table does not control the timing of when migration scripts are ran. Certainly, you can delete records in that table which would cause the migration scripts to be ran again, but that's not the issue here. What I'd like to hear about is why migration scripts are ran so early in the script, and not wait until after all the required DB objects are created. Especially when the db objects existed in the db long before the scripts were created.
mzamora, I agree. It would be a nice feature once it's working.
As a developer, I can tell some issues can be fixed easily enough with just more robust coding. It's clear the tool loads the source controlled information into memory and then never properly rechecks if anything has changed since the initial load. This causes all kinds of random errors. We have completely lost migration scripts because of crashes from this problem and had to start from scratch.
There are other issues that are more fundamental. Having read most of the documentation it seems that the Migration Scripts feature is focused on edge cases like, for example, working with new nullable columns where user intervention is required. If you read between the lines it seems like the message is that Red Gate does not have a solution yet for including the variety of scripts that get run on environments in a normal enterprise. If you don't believe that try to create a new database using Source Control 5 when you have a number of migration scripts and watch the mayhem ensue! / comments
Sergio, from what I understand, that table does not control the timing of when migration scripts are ran. Certainly, you can delete records in that table which would cause the migration scripts to ...
Thanks for confirming this for me. It seems like quite the oversight since work in agile teams is an iterative process.
Here's a possible workaround:
Except for very special cases all of our database scripts are re-runnable. They can be run multiple times on the same database without causing harm or errors.
Perhaps there's a way I can automate the deletion recent records from the DeploymentMetadata table every time a build is triggered. At least then I don't have to ask my developers to manually go in to tables on the different environments and find records to delete. (Also note that it not possible to copy the migration script id in SQL Source Control to the clipboard)
That feature request is mine [image] / comments
Thanks for confirming this for me. It seems like quite the oversight since work in agile teams is an iterative process.
Here's a possible workaround:
Except for very special cases all of our databa...
I added a step in Jenkins (our build server) in both our dev and test environments to run SQLCMD with "DELETE FROM RedGateLocal.DeploymentMetadata". It wipes the table every build. So far it hasn't caused any problems but I would be interested to know if it has drawbacks other than that the scripts are reran each time. / comments
I added a step in Jenkins (our build server) in both our dev and test environments to run SQLCMD with "DELETE FROM RedGateLocal.DeploymentMetadata". It wipes the table every build. So far it hasn't...
Has this been resolved? The scripts generated by our DLM Automation cmdlets are trying to reset our sequence values! / comments
Has this been resolved? The scripts generated by our DLM Automation cmdlets are trying to reset our sequence values!
I'm having the same issue in DLM Automation 2.0.1.2005. Is there a resolution for this issue? / comments
I'm having the same issue in DLM Automation 2.0.1.2005. Is there a resolution for this issue?