problem getting sequential revisions with migration scripts
freecell1
Posts: 33
We just hit an odd problem. We had two revisions, each with a few object changes and each with a migration script. Let's call them svn revisions 123 and 456. Developers who did a "Get Latest" to their local copies experienced the following:
1) If they already had 123 locally (from a prior update), SQL Source Control applied 456 correctly to their box.
2) If they had not gotten latest for a while and didn't have either change, the Get Latest page showed them the object list of changes from both 123 and 456, as expected. However, they received an error after clicking get latest, and if maybe the order of application was wrong.
I would expect that when getting multiple revisions, the tool would apply the scripts in order (123 then 456). But that did not seem to occur.
They tried to solve it by manually deselecting the objects in 456, applying just the 123 changes, and then doing 456. However that didn't work because applying any of the changes in the list set their local metadata (extended property of db) to version 456. Workaround was to Get Latest on 123 objects, manually set the extended property to 123, then apply 456.
This can't be how this works ... does anyone know the answer?
1) If they already had 123 locally (from a prior update), SQL Source Control applied 456 correctly to their box.
2) If they had not gotten latest for a while and didn't have either change, the Get Latest page showed them the object list of changes from both 123 and 456, as expected. However, they received an error after clicking get latest, and if maybe the order of application was wrong.
I would expect that when getting multiple revisions, the tool would apply the scripts in order (123 then 456). But that did not seem to occur.
They tried to solve it by manually deselecting the objects in 456, applying just the 123 changes, and then doing 456. However that didn't work because applying any of the changes in the list set their local metadata (extended property of db) to version 456. Workaround was to Get Latest on 123 objects, manually set the extended property to 123, then apply 456.
This can't be how this works ... does anyone know the answer?
Comments
From your description it does sound like you may have encountered a bug. However, before I can get the development team to take a look I will need to have replicated the problem on my own test machine.
Would it be possible for you to send me some step to recreate the problem? Hopefully including some example objects which you are confident will show me the bug in action. I can then use this to demo the problem to the dev team.
Please can you send this to support@red-gate.com and quote the support ticket number F0059671 in the subject line.