title: SSIS Package Not Running as 32bit in SQL Server 2012
body: <p>I have a package that I developed in VS2012 (using the SQL Data Tools component) which collects data from a DBF file using the VFPOLEDB provider, and puts it into a database on a SQL Server 2012 X64 server. The project containing the package has the DebugOption of Run64BitRuntime set to false. I have imported this package to the SSIS Package Store of a test and live server (identical setups). The VFPOLEDB provider is installed on both, and I can see in the registry of both machines that it's there for 32bit runtimes.</p>
  
  <p>The package runs fine on the test machine, but fails on the live machine. The live instance of SQL does not appear to recognize the 32bit VFPOLEDB provider that is installed.</p>
  
  <p>The only difference in the instances of SQL is that the live environment has an Integration Service Catalog set up, where as the test does not. Looking at the logs of the servers, when the live starts, it runs sp_ssis_startup, and then logs messages about unsafe assemblies being loaded in. This SP is not run on the test environment because there is no catalog.</p>
  
  <p>The jobs I create have the flag set to use the 32bit runtime, but I can't help but feel that the SSIS Catalog is having an issue with the VFPOLEDB I am using, and not loading it.</p>
  
  <p>I don't really know anything about the SSIS catalog, so is anyone able to suggest any direction I could move in?</p>
  
  <p>Update:
  Here is my job step configuration. The 32bit runtime flag is set.
  <img src="https://i.stack.imgur.com/M49aw.jpg" alt="SSIS Job Step Configuration"></p>
  
  <p>Update #2:</p>
  
  <ol>
  <li>OLEDB provider is installed appropriately.</li>
  <li>The same version of the provider is installed on both machines. </li>
  <li>The OBDCAD32.exe shows the same versions of the VFPOLEDB provider. No DSNs are defined on either machine. My local machine does have DSNs defined, so I will try adding one in for dBASE files and see if that helps.</li>
  <li>In the process of trying this step now. I am looking for a way to use the dtexec tool without having it create the SSISDB catalog. Although I did remove the existing SSIS catalog and stopped sp_ssis_startup being executed on service startup. I saw no log entries about an unsafe assembly, but the job still failed with the same error as it always has. I will report back on 4 and possibly further ask for further guidance.</li>
  </ol>
  
  <p>Update #3:<br />
  I have just checked and the test and live environments are not as identical as I had originally stated. The live server does not have the  32bit version of dtexec.exe (although I didn't think this would matter as <a href="https://msdn.microsoft.com/en-us/library/hh231187(v=sql.110).aspx#bit" rel="noreferrer">TechNet</a> says that jobs run with SQL Server Agent will always use the 64bit version. I think I used an x86 and i64 ISO to set up the test environment, but a 64bit only version for live. Changing this would require, I'd imagine, uninstalling the Integration Services shared component from the live box and reinstalling it with the dual iso.</p>
  
  <p>I guess setting the "Use 32bit runtime" option only works if there is a 32bit version to use? That might explain things.</p>