Activity overview
Latest activity by troyhunt
Great timing [image] https://twitter.com/troyhunt/status/1098117126026551297 / comments
Great timing https://twitter.com/troyhunt/status/1098117126026551297
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...
Login failed when using AD credentials from the command line
I'm trying to run SQL Compare 10 from the command line to sync a database under source control and a remote DB server as follows:
"C:\Program Files (x86)\Red Gate\SQL Compare 10\SQLCompare.exe" /sc...
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...
Compare just a single table via the command line
I'm struggling with something which should be very basic but I'm just not sure what I'm missing. I have two DBs from which I want to compare just a single table via the command line. I'm presently ...
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...