How can we help you today? How can we help you today?
annieluxton
Activity overview Badges (0) Posts (2) Comments (2)

Comments

Sort by recent activity
Hi Jessica, Thank you for your reply! To do this in SQL CI, should I add it as an option in the "Additional parameters" section of the TeamCity plugin? Like this - /NoAutoColumnMapping ? Cheers, Annie / comments
  1. Community
  2. DLM Automation
  3. Disable automatic mapping when deploying
Hi Jessica, Thank you for your reply! To do this in SQL CI, should I add it as an option in the "Additional parameters" section of the TeamCity plugin? Like this - /NoAutoColumnMapping ? Cheers, ...
0 votes
Hi there, I'd like to add my two cents regarding migration scripts. We also have had a huge amount of trouble with migration scripts. A lot of our problems seemed to stem from the fact that our DB schema wasn't setting explicit constraint names for PK, FK and default constraints, so we had to write special SQL to try and build up DROP statements for these elements. We've fixed this now so I expected our problems to go away, but it still seems to be an issue in the 'Validate database state' SQL CI step which runs from TeamCity upon each build. Even after having explicitly set constraint names, the 'Validate database state' SQL CI step which we run from TeamCity fails often when we are modifying a table that requires dropping constraints (e.g. modifying an index requires any FKs defined on it's columns to be dropped and recreated), saying it cannot find the system named constraint. This makes sense, because when we wrote those migration scripts, we weren't setting constraint names. But the puzzling thing is that the 'Validate database state' process first wants to apply all changes (compare blocks) from the migration scripts. I believe it does this because the 'scratch' database it creates to compare the scripts folder to has no records in the RedGateLocal.DeploymentMetadata table, therefore it seems all migration scripts as needing to be run. I have tried adding /Options:IgnoreMigrationScripts to the TeamCity plugin but it does not seem to stop this from happening. I can see that by default, it always adds /Options:UseMigrationsV2 as well. I do understand that this 'Validate database state' is trying to recreate the entire DB from scratch using the DB schema in the scripts, including old migration scripts, but I can also see how this can end up in situations where it just won't work anymore because the old migration scripts and/or the 'compare blocks' referred to elements that no long exist or clash with more recent changes, etc. Perhaps this is one of the reasons why migration scripts seem to be so damaging or hard to use, because they leave behind these 'snapshotted' compare blocks that just make no sense further down the line. The only work-around I can see is to delete all the migration scripts we've used. Doing this lets the 'Validate database state' pass without errors. Because of these sorts of issues, we have not used migration scripts for months now and have opted to have another process for deploying migration scripts instead - much like moesother described. We only use SQL Source Control for schema changes. Finally, I'm sad to say that myself and my team have wasted COUNTLESS days on this and in all honesty, I really did expect more from such an expensive product. I would be very interested in hearing if anyone else has experienced the same issues as I've described above, or come to the same conclusions, and whether there's a work around. / comments
  1. Community
  2. SQL Source Control
  3. Abandon using migration scripts
Hi there, I'd like to add my two cents regarding migration scripts. We also have had a huge amount of trouble with migration scripts. A lot of our problems seemed to stem from the fact that our DB ...
0 votes
Total activity
6
Last activity
Member since
Following
0 users
Followed by
0 users
Votes
0
Subscriptions
2