Comments
Sort by recent activity
Actually, as of TeamCity 7, passwords can be masked: http://youtrack.jetbrains.com/issue/TW-759
By adding an environment parameter of type "password" you can include the credentials in the build without disclosing them through any UIs. / comments
Actually, as of TeamCity 7, passwords can be masked: http://youtrack.jetbrains.com/issue/TW-759
By adding an environment parameter of type "password" you can include the credentials in the build wi...
Hi David, yes, it's from TeamCity. The problem with using the identity the agent runs under is that any build can then deploy to any location the agent's account has access to. For example, if both project A and project B use the agent's identity to deploy to their DB then there's nothing stopping the owner of project A configuring their deployment target to be the location of project B.
This is mostly a problem when the build server is used for multiple autonomous projects. Basically the only way you can segregate out access rights is to specify credentials on a per-build basis which is why I wanted to pass these to the command line. It's not a biggie, it just means automation needs to happen using SQL logins instead of AD.
Thanks for clarifying! / comments
Hi David, yes, it's from TeamCity. The problem with using the identity the agent runs under is that any build can then deploy to any location the agent's account has access to. For example, if both...
Beautiful, thanks Peter, the patched version is working just fine. / comments
Beautiful, thanks Peter, the patched version is working just fine.
Chris Auckland wrote:
1) Create a project in the GUI, and then reference the project file using /project switch
2) The /exclude switch still works, so you could exclude the tables you don't want.
Unfortunately number 1 is throwing the same exception against this syntax: SQLDataCompare.exe /pr:MyCompareFile.sdc
And number 2 would be rather unpleasant given the number of tables in the DB.
Any word on the timeline for a fix? / comments
Chris Auckland wrote:
1) Create a project in the GUI, and then reference the project file using /project switch
2) The /exclude switch still works, so you could exclude the tables you don't wa...
According to the features list, you'll need to go pro in order to compare against a folder of scripts from VCS: http://www.red-gate.com/products/sql-de ... e/features / comments
According to the features list, you'll need to go pro in order to compare against a folder of scripts from VCS: http://www.red-gate.com/products/sql-de ... e/features
David, from a greenfield perspective, I completely agree with you. The only concern I would have is breaking the behaviour experienced by existing customers. Having said that, I can't imagine a valid use case for why anyone would want the application to behave in this manner. / comments
David, from a greenfield perspective, I completely agree with you. The only concern I would have is breaking the behaviour experienced by existing customers. Having said that, I can't imagine a val...
Thanks James, but the problem is pretty much as you said; all tables will be compared. Sure, they're not synced but when you're dealing with large target tables the process spends a loooong time pulling down records which it ultimately does no comparison on anyway.
In this particular case, it makes the difference between 30 seconds when white listing the tables and 30 minutes when using /Exclude:additional. Plus, not being able to couple it with /Include:identical means when no sync is required, an error code is returned and the build is effectively broken.
Now that Red Gate has done such an excellent job with SQL Compare 2 and made getting static data into VCS a breeze, syncing just that data and leaving the transactional tables untouched seems like a logic next step. All the pieces of the puzzle are there, they just need to work together. Something along the lines of /Include:SourceOnly would be nice. / comments
Thanks James, but the problem is pretty much as you said; all tables will be compared. Sure, they're not synced but when you're dealing with large target tables the process spends a loooong time pu...
Thanks for the response James, certainly this would be a desirable feature.
I'm working on a continuous integration environment using the Red Gate tools for deployment which means SQL Compare and Data Compare on the server and SQL Source Control 2 on each client. In this scenario, creating a .sdc project would need someone to remote into the server, set it up and then version it. In fact even passing all the tables by the command line least means the build configuration needs to be changed each time a reference table is added or removed. From a continuous integration perspective, this gets very clunky.
Putting a white list of tables in an arg file is better, but still not ideal. In a perfect world, it would be good to see an option to only sync tables which appear in VCS. That way the developer could simply put the static data of a table into VCS and it would be implicitly deployed.
Here's an overview of the environment I'm working towards: http://www.troyhunt.com/2011/02/automat ... -with.html / comments
Thanks for the response James, certainly this would be a desirable feature.
I'm working on a continuous integration environment using the Red Gate tools for deployment which means SQL Compare and D...
Hi Chris, that's the trick. The problem I was having was assuming the sync would run against the tables in VCS only without any explicit inclusions or exclusions. What was happening was that the default behaviour was every single table was syncing when I used /Include:identical. When I didn't use it, the exe returned an error code when no changes were required which broke my CI build.
As soon as I removed the black-list and added a white-list, the excluded tables no longer synced as per your suggestion. It's a little bit odd - tables will sync unless there's a white-list they don't appear in - but it has answered the question. Thanks!
And yes, I'm using SQL Source Control 2 EA. I've written about this and the above question in part of a larger post here: http://troy.hn/hTh4yc / comments
Hi Chris, that's the trick. The problem I was having was assuming the sync would run against the tables in VCS only without any explicit inclusions or exclusions. What was happening was that the de...
After spending more time looking at this issue in depth, having Chris unsure of a resolution and not getting any other feedback from this post or the equivalent one on Stack Overflow - http://stackoverflow.com/questions/4302779/can-red-gate-sql-source-control-identify-a-case-change - I'm calling this one a bug. I'd love to be proven wrong, but that seems to be the case (sorry about the pun!).
So to specifically answer my question, no, it appears SQL Source Control can't natively version a case-only change. However, there is a workaround involving making the change in the working directory and submitting this back via TortoiseSVN (assuming the VCS is SVN). Th full details are now in "Defeating Red Gate’s SQL Source Control insensitivity" - http://www.troyhunt.com/2010/12/defeating-red-gates-sql-source-control.html / comments
After spending more time looking at this issue in depth, having Chris unsure of a resolution and not getting any other feedback from this post or the equivalent one on Stack Overflow - http://stac...