locked
DTEXEC 32 bit vs 64 bit RRS feed

  • Question

  • I wrote a vb.net utility that reads dtsx packages, allows connection string changes, tests the connection strings, and then deploys that changed packages using DTEXEC. I have it working on SQL 2005 and SQL 2008 on our test systems. But wonder about out in the field (we have many clients with varying systems) and 32 bit versus 64 bit versions of DTEXEC. Since I only use it for deploying packages, it should not matter is 32 or 64 bit is used ... correct? Is there something that I should be looking out for?
    Thursday, August 8, 2013 4:00 PM

Answers

  • Sorry, I assumed you were using an explicit path to the 32-bit dtutil executable, which would fail in the SQL Server 2012 scenario.  Incidentally, for your command line execution, I believe the executed version depends on the PATH environmental variable, not on the registry (see here).

    Yes, the dtsx files will be the same regardless of which version of dtutil.exe is used.  However, they will not be the same for SQL Server 2005 and 2008, which can cause misleading dtutil errors (e.g. here).

    The 32 bit dtutil.exe should be able to load packages for a 64-bit SQL Server, but that is something you should probably test.  I was not able to find a definite statement from someone who has done it successfully.

    • Edited by John Smith 3 Wednesday, August 14, 2013 5:20 PM blah
    • Marked as answer by TheBrenda Wednesday, August 14, 2013 5:31 PM
    Wednesday, August 14, 2013 5:14 PM

All replies

  • Since you're using this for deployment, I assume you mean dtutil, not dtexec?

    The documentation says SQL Server 2012 installs only the 64-bit version, but that if you have both, the 32-bit version runs by default.

    The 32-bit version runs because the directory path for the 32-bit version appears in the PATH environment variable before the directory path for the 64-bit version.

    If you've tested that it works with both versions, you should be okay.  If it only works with the 32-bit version, then you may have to think about the SQL 2012 scenario.  Of course, you can always install the 32-bit version and change the PATH.

    • Proposed as answer by John Smith 3 Wednesday, August 14, 2013 12:23 PM
    Thursday, August 8, 2013 4:49 PM
  • Yes DTUTIL. Sorry.

    But since I am just loading packages /COPY, does it matter if the 32 or 64 bit is used?  Will the 32 bit DTUTIL not be able to load packages to a 64 bit SQL Server?

    This is my statement

    dtutil /DestS %SSISSERVER% /FILE %FILENAME%  /COPY SQL;/%PACKAGENAME% /QUIET

    What do you mean "think about the SQL 2012 scenario"?

    Thursday, August 8, 2013 5:19 PM
  • SQL Server 2012 installs only the 64-bit version.  So if your deployment relies on the 32-bit version of DTUTIL (including to 64-bit SQL Server), it will fail in an environment where only SQL Server 2012 is installed.  That is the scenario I was referring to.  I mentioned it since you are concerned about deployment out in the field, where you have clients with varying systems.
    Wednesday, August 14, 2013 12:22 PM
  • I am confused. My vb.net utility program does not specify a dtutil path. So it will use which ever one is registered.  When you say "if your deployment relies on a 32 bit verion of DTUTIL" ... what does that mean? What would make a deployment rely on a 32 bit or a 64 bit deployment?

    I assum that packages are not 32 or 64 bit, they are just xml.

    for my statement, do i care which dtutil is selected (you can make the 32 bit and 64 bit dtutil install).

    dtutil /DestS %SSISSERVER% /FILE %FILENAME%  /COPY SQL;/%PACKAGENAME% /QUIET

    Wednesday, August 14, 2013 3:31 PM
  • Sorry, I assumed you were using an explicit path to the 32-bit dtutil executable, which would fail in the SQL Server 2012 scenario.  Incidentally, for your command line execution, I believe the executed version depends on the PATH environmental variable, not on the registry (see here).

    Yes, the dtsx files will be the same regardless of which version of dtutil.exe is used.  However, they will not be the same for SQL Server 2005 and 2008, which can cause misleading dtutil errors (e.g. here).

    The 32 bit dtutil.exe should be able to load packages for a 64-bit SQL Server, but that is something you should probably test.  I was not able to find a definite statement from someone who has done it successfully.

    • Edited by John Smith 3 Wednesday, August 14, 2013 5:20 PM blah
    • Marked as answer by TheBrenda Wednesday, August 14, 2013 5:31 PM
    Wednesday, August 14, 2013 5:14 PM