Is my SSIS package running in 32 or 64 bit mode?

32 versus 64 bit backstory

I might have looked at some of the questions over on StackOverflow and I've lost track of the number of times a package has worked but then it doesn't on another machine and it ends up being a mismatch between the "bittedness" of their driver and their execution model.

32 or 64 bit?

Windows was a 32 Operating System, OS, until around 2003. In the main Windows folder, you had a System folder, which was for 16 bit libraries, and System32 folder, which was for 32 bit libraries and applications. All is well and good.

Then the 64 architecture made it into Windows and now we have a third folder, this one called SysWoW64 which contains? .... 32 bit applications. Of course. The 64bit applications and libraries are in the System32 folder. I am not making this up. So, 32 bit in the folder named 64, 64 bit in the folder named 32. Got it.

But wait, there's more. Not only can your OS come in 32 and 64 bit flavours, so can your applications and drivers! Applications usually install in the Program Files directory. If you are on a 64 bit OS, then your "Program Files" is going to contain your 64 bit executables while your "Program Files (x86)" will contain your 32 bit executables. But don't worry, if you're on a 32 bit OS, there won't be an (x86) folder and the 32 bit executables will be in "Program Files."

So what?

Think of 32 vs 64 bit as height in inches. A two year old is probably 32" while a 17 years old may be 64". If I put a knick knack on the top shelf, only the 17 year old can reach (address) it. If I make the mistake of putting it on a low shelf, 17 year old can't be bothered to bend down to pick it up but the 2 year old can and will do their best Godzilla impersonation on it.

What's drivers got to do with it

SSIS can target a variety of sources and sinks out of the box. Flat files, web services, Active Directory, SQL Server: piece of cake. Excel, Access, Informix, DB2, MySQL, Oracle: not so much with the cake. The problem is that you need special drivers to get SSIS to talk to these providers. Some, like Excel^* are part of the base installation. Others might require an special download.

Some drivers come in both kinds, 32 and 64 bit. Others, are only found in the 32 bit variety. I'm sure there's some esoteric driver that only works in 64 bit but I've never found someone lamenting this on a forum.

Often, with these providers, you will create a Data Source Name, DSN, to provide configuration information or provide your own unique file that starts with TNS and ends with ORA. What's important to realize is that you will need to align these configuration values with the correct bit version of your driver and your target package execution mode.

The executable for ODBC driver administration is odbcad32.exe. That tool exists in SysWow64, our 32 bit app location, and also in System32, our 64 bit app location but it's still physically called odbcad32.exe in both locations. Have I mentioned I deal with this confusion with some frequency? I don't know why, it seems so readily apparent. Further muddying the waters, I believe it was the Server 2003 the Control Panel, Administrator Tools, ODBC Data Sources only pointed to one of them. You had to know the other existed and find it to use it. The current interface at least lists it twice and indicates which is 32 versus 64 bit.

Running SSIS packages

SSIS packages "run" by getting called from an executable named dtexec.exe. If you have SSIS/BIDS/SSDT installed on your machine, you likely have two versions of dtexec.exe. Assuming default paths, you likely have the following them installed at the following paths.

SQL Server Version	32 bit	64 bit (default)
2005	C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe	C:\Program Files\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
2008	C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe	C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
2012	C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\DTExec.exe	C:\Program Files\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
2014	C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\DTExec.exe	C:\Program Files\Microsoft SQL Server\120\DTS\Binn\DTExec.exe

This matters as the default executable that gets run will likely be the 64 bit version. If you're trying to execute a package in 32 bit mode from the command line, you will need to explicitly reference the dtexec.exe in the x86 folder.

Observant folks may see that the dtexec offers a /X86 option. Don't believe it. The only way to get the correct bit-ness is to explicitly call the correct dtexec.exe The documentation even says as much but nobody reads documentation. This option is only used by SQL Server Agent. This option is ignored if you run the dtexec utility at the command prompt.

SSISDB notes

For those working with the Project Deployment Model (2012/2014), you don't have to worry about paths when spawning an execution instance. It's a simple matter of passing True/False to the @user32bitruntime parameter (line 6 below)

   1:  EXEC [SSISDB].[catalog].[create_execution]

   2:      @package_name = N'PartialLookup.dtsx'

   3:  ,   @execution_id = @execution_id OUTPUT

   4:  ,   @folder_name = N'POC'

   5:  ,   @project_name = N'BimlTest'

   6:  ,   @use32bitruntime = True

   7:  ,   @reference_id = NULL

Tracking whether an execution instance was 32 or 64 bit isn't readily apparent with the native reports but a simple query against catalog.executions will reveal it.

SELECT
    E.use32bitruntime
,   *
FROM
    catalog.executions AS E
WHERE
    E.execution_id = @OperationIDFromReportUpperLeftCorner;

Putting it all together, mostly

If I'm in 32 bit space, I can only work with the drivers and data source names I know about. The DSN I'm looking for might be in 64 bit space but I'll never be able to reach it from the depths of 32 bit. To paraphrase: 32 is 32, and 64 is 64, and ne'er the twain shall meet.

You might swear up and down you created the DSN or ran it in 32 bit mode but JET's not installed and this a bug with SSIS but before you post a question on StackOverflow, the MSDN forums or Connect, double check.

How do I double check?

Finally, what I was originally putting this post together to cover. For 2012/2014 packages in the project deployment model, you already have your answer. For everything else, there's a Script Task.

I know, I heard you saw ewwwww. It's not true. When you run your package from the command line, the first two lines

Microsoft (R) SQL Server Execute Package Utility
Version 12.0.2000.8 for 64-bit

Right there, it says this is the 64 bit version of dtexec and that I don't need to patch my VM. But, there are other ways of invoking a package. What if I started my package via .NET code or am running it in Visual Studio?

The quickest way I've been able to determine is to evaluate IntPtr.Size. If it's 4, then it's 32 bit, if it's 8, then it's 64.

Assuming you pass in System::InteractiveMode as a read parameter, this little script will fire an information event alerting you whether you're 32 or 64 bit. It can also pop up a message box, because everyone loves those.

            bool fireAgain = false;
            string message = string.Empty;
            message = string.Format("I am running in {0} mode", (IntPtr.Size == 4) ? "32 bit":"64 bit");
            Dts.Events.FireInformation(0, "Log bittedness", message, string.Empty, 0, ref fireAgain);
            if ((bool)this.Dts.Variables["System::InteractiveMode"].Value)
            {
                MessageBox.Show(message);
            }

Biml

A post wouldn't be complete without some Biml! If you wanted to, you could add this little bit into every package you emit and then you'd know, absolutely know whether stumbled onto a bug or the problem exists between keyboard and chair.

Don't be afraid of that hot mess of code. All it does is generate an SSIS package that uses a Script Task that has the above code in it. You can use the CallBimlScript trick from the Replicate-O-Matic post to encapsulate the script task into an external file but that's not really as flexible as I'd want it to be.

<Biml xmlns="http://schemas.varigence.com/biml.xsd">

<ScriptProjects>
    <ScriptTaskProject ProjectCoreName="ST_12345" Name="ST_12345" VstaMajorVersion="0">
        <ReadOnlyVariables>
            <Variable Namespace="System" VariableName="InteractiveMode" DataType="Boolean" />
        </ReadOnlyVariables>
        <Files>
            <File Path="ScriptMain.cs" BuildAction="Compile">using System;
using System.Data;
using Microsoft.SqlServer.Dts.Runtime;
using System.Windows.Forms;

namespace ST_12345
{
    [Microsoft.SqlServer.Dts.Tasks.ScriptTask.SSISScriptTaskEntryPointAttribute]
    public partial class ScriptMain : Microsoft.SqlServer.Dts.Tasks.ScriptTask.VSTARTScriptObjectModelBase
    {
        public void Main()
        {
            bool fireAgain = false;
            string message = string.Empty;
            message = string.Format("I am running in {0} mode", (IntPtr.Size == 4) ? "32 bit":"64 bit");
            Dts.Events.FireInformation(0, "Log bittedness", message, string.Empty, 0, ref fireAgain);
            if ((bool)this.Dts.Variables["System::InteractiveMode"].Value)
            {
                MessageBox.Show(message);
            }

            Dts.TaskResult = (int)ScriptResults.Success;
        }

        enum ScriptResults
        {
            Success = Microsoft.SqlServer.Dts.Runtime.DTSExecResult.Success,
            Failure = Microsoft.SqlServer.Dts.Runtime.DTSExecResult.Failure
        };
    }
}                </File>
            <File Path="Properties\AssemblyInfo.cs" BuildAction="Compile">
using System.Reflection;
using System.Runtime.CompilerServices;

//
// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
//
[assembly: AssemblyTitle("AssemblyTitle")]
[assembly: AssemblyDescription("Bill is awesome")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("")]
[assembly: AssemblyProduct("ProductName")]
[assembly: AssemblyCopyright("Copyright @  2015")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]
//
// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Revision and Build Numbers
// by using the '*' as shown below:

[assembly: AssemblyVersion("1.0.*")]
                </File>
        </Files>
        <AssemblyReferences>
            <AssemblyReference AssemblyPath="System" />
            <AssemblyReference AssemblyPath="System.Data" />
            <AssemblyReference AssemblyPath="System.Windows.Forms" />
            <AssemblyReference AssemblyPath="System.Xml" />
            <AssemblyReference AssemblyPath="Microsoft.SqlServer.ManagedDTS.dll" />
            <AssemblyReference AssemblyPath="Microsoft.SqlServer.ScriptTask.dll" />
        </AssemblyReferences>
    </ScriptTaskProject>
</ScriptProjects>
<Packages>
    <Package Name="CheckMyBits" ConstraintMode="Linear">
        <Tasks>
            <Script ProjectCoreName="ST_12345" Name="SCR Do Stuff">
                <ScriptTaskProjectReference ScriptTaskProjectName="ST_12345" />
            </Script>
        </Tasks>
    </Package>
</Packages>
</Biml>

That's a lot of Biml to try and remember, if only there was a way to keep that handy...