Can the ArgFile parameter be used with other parameters?
troyhunt
Posts: 17 Bronze 3
I'm running Data Compare from a TeamCity CI environment and it needs to do a comparison against a fairly large number of tables (over 50, in this case). This is way too clunky to put in the command line so I've been putting them in an XML arguments file and referencing it using the ArgFile parameter.
The problem is, I want to pass other parameters via the command line. For example, there are certain variables I can only get directly from TeamCity and can't hard-code into the args file. Although I can't find an explicit reference to not using ArgFile with other params, every time I run the build I'm seeing errors like this:
"Error: The /argfile switch cannot be used in conjunction with the /server2 switch"
Moving the particular switch in the error to the arguments file (i.e. "server2"), simply causes the build to file on a different switch.
So the question is this: can the ArgFile param be used with other command line params or is it simply one or the other?
The problem is, I want to pass other parameters via the command line. For example, there are certain variables I can only get directly from TeamCity and can't hard-code into the args file. Although I can't find an explicit reference to not using ArgFile with other params, every time I run the build I'm seeing errors like this:
"Error: The /argfile switch cannot be used in conjunction with the /server2 switch"
Moving the particular switch in the error to the arguments file (i.e. "server2"), simply causes the build to file on a different switch.
So the question is this: can the ArgFile param be used with other command line params or is it simply one or the other?
Comments
Unfortunately, the behaviour you see is correct. There are a couple of options that can be used with the /argfile switch as detailed here but they aren't really of any use for your situation.
I'll log this as a feature request however, as I can see the sense in wanting to use XML to specify the tables to use but still use other switches in combination with this.
One other thing you could try is setting up your tables to use and saving an .sdc project. You can reference this using the /Project switch, and based on a quick test, you can still combine this with the /server2 /database2 switches.
Redgate Software
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
This should exclude objects not present in the source, the end result of which is you shouldn't get any data removed from the target of your deployment, as although all tables will be compared, any where you have rows in the target but not in your source-controlled scripts (i.e. transactional data) will be skipped from the sync.
This cannot be combined with the /Include switch unfortunately; but if used alone it achieves what you're after, then that's not a problem.
I'm not 100% sure it will work exactly as you want, but it's perhaps worth trying - if not, let us know and we can investigate improvements that can be made to the application itself.
Redgate Software
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.
Can you think of any reason why we shouldn't simply change the behaviour so that in all cass where the source is a scripts folder, SQL Data Compare should never consider tables that don't exist in the data folder?
David Atkinson
Product Manager
Red Gate Software
Product Manager
Redgate Software
I think the kind of change David is suggesting would maybe be configurable as an option so as to not confuse existing customers, although he's in a better position than myself to check that.
Redgate Software
The capability of the SQL Data Compare command line to using a scritps folder as a source was implemented specifically to allow build automation processes. Unless someone comes up with a reason why someone would want to compare tables that only exist in the target when the source is a scripts folder, I vote we change the behaviour.
David
Product Manager
Redgate Software