Activity overview
Latest activity by brucevanhorn2
Is this still considered a valid answer? I have a migration script from last year that references a field that no longer exists. When I go to apply to an empty database (or a full one from a database restore, say from production) I can't because the old migration script will always fail. To fix it, I had to check out the repository to a normal folder, delete the offending script and alter the json file that determines the patch order so that entry is no longer there. I committed then went back to SSMS, refreshed on the "Get Latest" tab and found the script wasn't there anymore. After that, the update worked. / comments
Is this still considered a valid answer? I have a migration script from last year that references a field that no longer exists. When I go to apply to an empty database (or a full one from a data...
This is happening to me today. I realize it's been 2 years, but here we are. I'm using Octopus Deploy to deploy the database, other than that it seems to be very similar. Per Mohit's suggestions, I did verify changes were made, and checked in. We have a step in team city that attempts to apply the changes directly to an empty database before sending it to Octopus. All the changes are present in the empty database, but our development test and staging database, which both say they have been successfully updated, don't ever change. We can use SQL Compare to see the differences and manually deploy, but our automated workflow, which has worked for over a year, is suddenly failing and the only thing I can point to right now is the message that says "The update script doesn't contain any SQL statements. Skipping the update. " Any other ideas on what to check?
/ comments
This is happening to me today. I realize it's been 2 years, but here we are. I'm using Octopus Deploy to deploy the database, other than that it seems to be very similar.Per Mohit's suggestions, ...
They changed the way migration scripts worked a while back. I'd make sure the migration script you created (that isn't working) was created in the right version with respect to the release of DLM you're using. / comments
They changed the way migration scripts worked a while back. I'd make sure the migration script you created (that isn't working) was created in the right version with respect to the release of DLM ...
The update script doesn't contain any SQL statements. Skipping the update.
I'm using Team City and Octopus Deploy with DLM and recently my database developer started complaining that the deploys we were getting were incomplete. I synced a test database with our dev datab...
I know this doesn't help you, but I'm having the same problem. I have a very different setup though. In my case DLM is just ignoring my changes. I can see them in the octopus package (I use team city and octopus deploy) but it just breezes past the changes and says "There are no sql statements in the update script". / comments
I know this doesn't help you, but I'm having the same problem. I have a very different setup though. In my case DLM is just ignoring my changes. I can see them in the octopus package (I use team...
Is there a reason why you wouldn't ultimately have someone check those amendments in? I get sometimes you need to make a quick adjustment on the fly to get a test to pass and a release out the door, but I think the answer to your question is no-you can't tell octopus / red gate to only deploy newer changes - their job is to bring the schema into sync with what's checked in. Making changes outside that cycle are problematic. Maybe if you made your spot changes in a difference schema it might work, but that doesn't make it a good idea. / comments
Is there a reason why you wouldn't ultimately have someone check those amendments in? I get sometimes you need to make a quick adjustment on the fly to get a test to pass and a release out the doo...