Can the ArgFile parameter be used with other parameters?

troyhunttroyhunt 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?

Comments

  • Thanks for your post.

    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.
    Systems Software Engineer

    Redgate Software

  • 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
  • We've just been discussing this a little further here. So the main issue boils down to you ideally wanting the deployment you run via Data Compare to only look at tables which actually have data (i.e. ones where there is something in the Data folder in your set of scripts). This is something we can investigate adding an option for, but I'm also wondering whether the "/exclude:additional" switch would help?
    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.
    Systems Software Engineer

    Redgate Software

  • 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.
  • Troy,

    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
    David Atkinson
    Product Manager
    Redgate Software
  • 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.
  • Based on your timings, I think it's understandable why you need to specify the tables!

    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.
    Systems Software Engineer

    Redgate Software

  • troyhunt wrote:
    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.

    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
    David Atkinson
    Product Manager
    Redgate Software
Sign In or Register to comment.