Comments
Sort by recent activity
Part 2 of my test results
- 'sharing' the migration scripts folder was a bad idea. [image] The second branch always try to destroy the scripts added by the first branch (sees it as a pended delete).
- I came back to my original setup and tested some more with SQL Compare. The only case I will see the migration scripts detect properly is when I use the 'B1' branch (my development branch) as the source of comparison. It never seems to work when trying to generate from the production branch.
A bit more of background:
We are working with a 'code promotion' type of branching strategy for our code, and our database needs to follow the same path as well. Most of the database changes are done from our 'DEV' branch. They eventually get merged (promoted) to our QA branch and finally to STABLE branch (production). The latter is where the version upgrade scripts for our system are usually generated from.
Hope this helps
Marc / comments
Part 2 of my test results
- 'sharing' the migration scripts folder was a bad idea. The second branch always try to destroy the scripts added by the first branch (sees it as a pended delete).
- I c...
Hi,
I have a setup that is very similar to what Scott described, and I recently upgraded from SSC 2.0 to 3.0. I am still evaluating how I need to set things up to take best advantage of the new Migrations feature.
Reading this thread got me asking this question: If you merge changes that contain a migration script from development branch to production branch, but always generate the upgrade script from Production branch, wouldn't that allow the tool to pick up the migration script properly? If so then I could easily work with that constrain as usually we will generate our scripts (and app builds) from the more stable branch.
Thanks
Marc / comments
Hi,
I have a setup that is very similar to what Scott described, and I recently upgraded from SSC 2.0 to 3.0. I am still evaluating how I need to set things up to take best advantage of the new Mig...
Thanks for the quick reply David, I will set it up accordingly and try it out to see the exact result. I'll post back once I've done my test.
Thanks
Marc / comments
Thanks for the quick reply David, I will set it up accordingly and try it out to see the exact result. I'll post back once I've done my test.
Thanks
Marc
I have setup a simple test scenario, where I have a source-controlled database with two tables. I've linked the database and then committed it, and then immediately branched the result in Vault. I now have two branches of the same DB. I linked and did Get Latest on second branch (B2) and all went well.
I then returned to B1 and did a schema change to which I attached a migration script. I added an INSERT statement at the end of the migration script. Committed the change to B1. Merged the change from B1 to B2. Then I opened SQL Compare to generate my script. The migration script part is not getting picked up. I can see the migration script in B2 through SSC as well as in Vault, but for some reason when trying to generate scripts from version X to latest, it will be ignored even through it is part of the changesets interval selected in SQL Compare. Same thing when initiating the comparison from SSC (with the Deploy/Schema menu).
Not sure if there's something I'm doing wrong or if it just fails in considering the migration scripts to build up the production compare script.
I will try to leave the migration scripts folder as 'shared' between the branches - from the documentation and tooltips when initially installing SSC 3.0 it seems like it was recommended to avoid branching the migration scripts folder. I will see how that reacts in my branched DB scenario.
Any clues/directions/suggestions also appreciated.
Thanks
Marc / comments
I have setup a simple test scenario, where I have a source-controlled database with two tables. I've linked the database and then committed it, and then immediately branched the result in Vault. I ...
Hi, not sure if I should try to revive this thread vs creating a new one, but I just had the exact same symptoms as initially posted here: Show History sits at the "Waiting for other operations to complete" for ages. I am running version 3.0.6.25, which seems is the latest to date.
When I give up the history dialog I also have the problem of SSMS process being stuck in execution. I have to kill the process from Task Manager and restart SSMS.
After killing the task and restarting, I went to do Show History on the same database again, this time it seems to be working its way through. It is still a slow process to bring up the history (especially "4/4 calculating changes", well over 20 minutes and still processing as I write this). But it was the very first SSC-related operation I did after restarting SSMS. It seems if you work for a while with the tool, at some point the Show History just gets stuck and stops working. I wish I could be more specific as to the circumstances or operations that can lead to this state, but for now this is all I have. I'm keeping an eye open on any piece of information worth sharing and will report back if anything comes up.
Thanks / comments
Hi, not sure if I should try to revive this thread vs creating a new one, but I just had the exact same symptoms as initially posted here: Show History sits at the "Waiting for other operations to ...
I want to correct myself on my previous post. I actually did not need to delete TableDataConfigs.xml on other workstations I upgraded since then. The reason it failed even though I cleared the "LinkedDatabases.xml" is, I believe, because I also had that file under a "SQL Source Control 1" folder in my AppData. This was likely a remnant for an earlier EAP release when the version was still numbered 1.x. I'm guessing the RC release tries to "convert" somehow to file from "SQL Source Control 1" folder and bring it to "SQL Source Control 2" folder, making it fail again on startup.
So, I had to delete "LinkedDatabases.xml" under "SQL Source Control 2" and I deleted the entire folder "SQL Source Control 1" and then the RC started without errors.
Hope this helps clarify what happened.
Thanks / comments
I want to correct myself on my previous post. I actually did not need to delete TableDataConfigs.xml on other workstations I upgraded since then. The reason it failed even though I cleared the "Lin...
This RC release breaks down our developers setup. On each of our 3 developer workstations (2 win7 + 1 win XP), after upgrading to the RC, SQL Source Control will just not load. At the SSMS splash screen we get the Red Gate error reporting window with a message "Exception has been thrown by target of invocation".
We're all using SQL Server 2008 R2 Express Edition with local dev db
Please help!
Thanks
Marc-Andre / comments
This RC release breaks down our developers setup. On each of our 3 developer workstations (2 win7 + 1 win XP), after upgrading to the RC, SQL Source Control will just not load. At the SSMS splash s...
Hi Tanya,
Yes I am using Vault.
Note that I also had to clear my "TableDataConfigs.xml" file to make it work.
Thanks
Marc-Andre / comments
Hi Tanya,
Yes I am using Vault.
Note that I also had to clear my "TableDataConfigs.xml" file to make it work.
Thanks
Marc-Andre
Hi,
For the last week I have tried the v1.1 EA that supports SG Vault as back-end for source control. I'd be interested in looking at the data sync features of this EA build as well, but does it also support SourceGear Vault as a source control back-end ?
Regards / comments
Hi,
For the last week I have tried the v1.1 EA that supports SG Vault as back-end for source control. I'd be interested in looking at the data sync features of this EA build as well, but does it al...
Hi,
Beyond the timebomb date what are our options if we want to pursue working/evaluating the product with Vault ?
I just found out about this EA build last week through a Vault newsletter and we are very interested in the product and looking to adopt it as soon as it becomes available.
Best Regards / comments
Hi,
Beyond the timebomb date what are our options if we want to pursue working/evaluating the product with Vault ?
I just found out about this EA build last week through a Vault newsletter and we a...