Activity overview
Latest activity by maturmel
Hi Chris,
No worries for the delay. I have been busy as well. [image]
For an online session, it works best for me on mornings. Tomorrow and Friday are good for me. Anytime between 9-12 EDT.
Can you email me at marct[AT]technicost.com and we can schedule a phone appointment. I will setup a session using http://join.me
I have a batch file invoking the SQL Compare command line already setup to replicate the issue at will.
Thank you very much.
Marc-Andre / comments
Hi Chris,
No worries for the delay. I have been busy as well.
For an online session, it works best for me on mornings. Tomorrow and Friday are good for me. Anytime between 9-12 EDT.
Can you email ...
Hi Chris,
I believe the following sequence would mimic what I have been doing:
1) create a new table "table_b"
2) check in
3) check in some other file (no SQL related) to the repo
4) try to deploy with source being the revision number obtained by check-in at step #3.
What I'm trying to achieve is to actually deploy code+DB kind of "all at once" as check-ins in steps #2 and #3 in the above would represent my DB changes and VS code related to db changes.
Also, maybe it's something in my command-line parameters (I first found it from CMD line but also replicated in SQL Compare UI). Here's the command line I executed:
SQLCompare.exe /sourcecontrol1 /revision1:<revisionnumber> /scriptsfolderxml:scriptsfolderxml.xml /migrationfolderxml:migrationsfolderxml.xml /db2:<target_db>
/server2:(local) /Include:Identical /Report:BuildPackage\SchemaDiffReport.html /ReportType:Interactive /ScriptFile:BuildPackage\SchemaUpdate_version.sql /Force /Verbose
If that can help I am willing to setup a web link to demo it directly on my server.
Marc-Andre / comments
Hi Chris,
I believe the following sequence would mimic what I have been doing:
1) create a new table "table_b"
2) check in
3) check in some other file (no SQL related) to the repo
4) try to deploy ...
Thanks for replying Brian. I also got notification that a support ticket was opened - under reference # F0064326. / comments
Thanks for replying Brian. I also got notification that a support ticket was opened - under reference # F0064326.
explicit revision number may destroy target database
Hi,
I have noticed that when using sqlcompare command-line with parameters:
/sourcecontrol1 and /revision with a specific revision number, if that number does not happen to be a changeset that incl...
Hmmm... well it seems things could have been much more simple if I had the following idea sooner.
I found files under
C:\Program Files (x86)\Red Gate\SQL Source Control 3\Vault
All those DLLs are from Sourcegear and of version 5.1.1
By copying the same DLLs from my Vault 6 folder into the above folder (and overwriting the 5.1.1 DLLs with 6.0.0), and restarting SQL Source Control/SSMS, now I can link to Vault again and Get Latest/Commit works just fine.
This is a much easier way to proceed than trying to do command-line hooks or manually check out/in files with the Vault client...
Again I thought I'd share what I found in case someone else out there is in the same pain I was since upgrading to Vault 6... now pain is gone [image]
Marc-Andre / comments
Hmmm... well it seems things could have been much more simple if I had the following idea sooner.
I found files under
C:\Program Files (x86)\Red Gate\SQL Source Control 3\Vault
All those DLLs are f...
Any updates from Red Gate on when Vault 6.0 could become supported ?
Also, in the meantime, it would be good to have your product page state that this new version isn't supported. The way it's currently worded does not suggest that at all (it says "Vault 5.1 and later").
Link: http://www.red-gate.com/products/sql-de ... quirements
Thanks
Marc-Andre / comments
Any updates from Red Gate on when Vault 6.0 could become supported ?
Also, in the meantime, it would be good to have your product page state that this new version isn't supported. The way it's curr...
You got my vote on that. [image]
Thanks for posting. / comments
You got my vote on that.
Thanks for posting.
While trying to setup a custom config xml file for interfacing with Vault 6.0 command line fails (CLI parameters do not properly map to available macros in the xml file + you need to put credentials straight in the CL), I manage to get things working by providing a blank config xml file (no commands for all source control calls). The effect is that while it does not at all interact with the Source control client, it still commits/gets changes using my local drive working folder as the reference. From there I can get/check out/check in using my standalone Vault client.
Although working this way requires more manual work, I came across one benefit of using SSC this way: it's allowing you to commit (check-in) code AND database as a single changeset, since you're controlling everything from your source control client.
Thought I'd just put it out there.
Marc-Andre / comments
While trying to setup a custom config xml file for interfacing with Vault 6.0 command line fails (CLI parameters do not properly map to available macros in the xml file + you need to put credential...
Consider this idea: create a 'dummy' table where you will add a new column to it for each migration script you wish to 'attach' to you DB. The dummy table itself would never contain any data. It would be a way for you to integrate your scripts into SSC and therefore benefit from all your automation setups... Of course a dummy table will not please people who tend to keep things ultra clean, but it's tradeoff that seems would offer big wins in terms of automation in this situation...
At least until SSC supports adding straight migration scripts as a whole feature... which, from the link you provided, would come eventually.
Marc-Andre / comments
Consider this idea: create a 'dummy' table where you will add a new column to it for each migration script you wish to 'attach' to you DB. The dummy table itself would never contain any data. It wo...
+1
Aside the "committed" rows of a specific check-in, everything seems to be already ordered by PK in the text file dump. The new & modified rows appear either at the top or at the bottom of the file.
It does make branch merging a little nightmarish. Seems like keeping the order across all rows in the text dump would improve usability of branching merging with SQL Source Control.
This should be made a feature request that we can vote on.
Marc-Andre[/code] / comments
+1
Aside the "committed" rows of a specific check-in, everything seems to be already ordered by PK in the text file dump. The new & modified rows appear either at the top or at the bottom of the fi...