5

I am receiving the following error when trying to run the package from the Integration Services catalog in SSMS. I changed the 64BitRuntime option to FALSE but it still does not work. The error below is followed by an error that a connection cannot be made to my Excel connection manager. Any suggestions?

Package Error: The requested OLE DB provider Microsoft.Jet.OLEDB 4.0 is not registered. If the 64-bit driver is not installed, run the package in 32-bit mode. Error code: 0x00000000

Hadi
  • 36,233
  • 13
  • 65
  • 124
Scottdg
  • 113
  • 1
  • 2
  • 12
  • Just to verify, add a new package to the project that will make it dreadfully obvious whether you're [running in 32 or 64 bit mode](http://billfellows.blogspot.com/2015/02/is-my-ssis-package-running-in-32-or-64.html) – billinkc Mar 29 '17 at 13:54
  • Thanks for the link but I have to admit it is not dreadfully obvious. I am not sure what adding a new package tells me. Am I recreating my package? Sorry I don't follow. I also failed to point out I am running this in deployment model and it works fine from Visual Studio. – Scottdg Mar 29 '17 at 14:57
  • Sorry, tea hadn't kicked in yet. Yes, you clearly stated `trying to run the package from the Integration Services catalog in SSMS` There are a few different ways of running it from SSMS. Are you connected to the Integration Services Catalog (2012+) or are you using the SSMS connection type of [Integration Services](https://i.stack.imgur.com/XoGPK.png) – billinkc Mar 29 '17 at 15:11
  • Integration Services Catalog (2012+) – Scottdg Mar 30 '17 at 12:42

5 Answers5

4

if you are executing the SSIS package from job , there is an option in job configuration a checkbox "enable 32 bit".

OR

if you are executing the SSIS package from BIDS or SSDT , go to project properties=> Configuration => debugging => turn 64BitRuntime from "True" to "False" as it is set to True by default.

fahad
  • 154
  • 6
  • Not running from a job. Failing when I execute it from the catalog. It is executing fine from SSDT. – Scottdg Mar 30 '17 at 12:45
  • tried the second option above? try to turn 64BitRuntime from True to False in the Project properties within the solution tell me which architecture version you are using for sql server 32/64? on which the package is deployed – fahad Mar 30 '17 at 15:20
  • Yes - you can see what is happening in my response to Hadi's post above. – Scottdg Mar 30 '17 at 19:34
  • In Visual Studio 2019, the option "64BitRuntime" is in the Solution Properties dialog, under debugging. – Mike Apr 16 '20 at 14:05
3

You are attempting to run an SSIS package from the SSISDB catalog and need it to be in 32 bit mode.

The TSQL for such would look like the following

DECLARE @execution_id bigint;
EXEC SSISDB.catalog.create_execution
    @package_name = N'Legacy_DataExport.dtsx'
,   @execution_id = @execution_id OUTPUT
,   @folder_name = N'Legacy_DataExport'
,   @project_name = N'Legacy_DataExport'
,   @use32bitruntime = True
,   @reference_id = NULL;
SELECT
    @execution_id;
DECLARE @var0 smallint = 1;
EXEC SSISDB.catalog.set_execution_parameter_value
    @execution_id
,   @object_type = 50
,   @parameter_name = N'LOGGING_LEVEL'
,   @parameter_value = @var0;
EXEC SSISDB.catalog.start_execution @execution_id;
GO

Of note is the penultimate parameter of the first EXEC where we specify @use32bitruntime = True

That says, please run the package Legacy_DataExport.dtsx which can be found in the project Legacy_DataExport which can be found in the folder Legacy_DataExport using the 32bit runtime.

From the UI perspective, it looks like

enter image description here

The click path within SSMS for this would be

  • Expand the "Integration Services Catalogs" node under "Management"
  • Expand the only option there of "SSISDB"
  • Expand the Folder where your project exists - "Legacy_DataExport" in my case
  • Expand the "Projects" node
  • Expand your actual project node - my project is also called "Legacy_DataExport"
  • Expand "Packages"
  • Find your package, again my example is "Legacy_DataExport.dtsx", right click it and select Execute...
billinkc
  • 59,250
  • 9
  • 102
  • 159
2

You have to install Microsoft Access Database Engine 2010 Redistributable and
set 64BitRuntime option to FALSE

you can get it from the following link:

More info and details can be found in the following links:

Hadi
  • 36,233
  • 13
  • 65
  • 124
  • It is installed and I set the option to false. – Scottdg Mar 30 '17 at 12:55
  • Also, aren't I running it on the server when I execute the package from the catalog? I can run the package from SSDT with no problem. – Scottdg Mar 30 '17 at 13:40
  • @Scottdg i provided new links in my answer. You can check them. I think this is what u are looking for – Hadi Mar 30 '17 at 14:27
  • The first one is very useful – Hadi Mar 30 '17 at 14:53
  • http://sqlblog.com/blogs/john_paul_cook/archive/2010/03/24/running-32-bit-ssis-in-a-64-bit-environment.aspx – Hadi Mar 30 '17 at 14:53
  • So the answer I got is that the Access 2010 engine was already installed and he installed the Access runtime. I am now getting a permissions error saying that either the file is opened exclusively or you do not have permission. I have permission to the folder and the file is not open by anyone. I am beginning to wonder if it is worth using Excel files. – Scottdg Mar 30 '17 at 18:45
  • You can try installing [process monitor](https://technet.microsoft.com/en-us/sysinternals/bb896645) to checkout what is happening when executing the package – Hadi Mar 30 '17 at 19:01
  • Check this links . They have a similar issue https://social.msdn.microsoft.com/Forums/sqlserver/en-US/d45a39a6-7170-4946-b30d-f760e4e509b7/ssis-2012-agent-job-errors-with-excel-data-source-the-microsoft-office-access-database-engine?forum=sqlintegrationservices – Hadi Mar 30 '17 at 19:07
  • http://dba.stackexchange.com/questions/81400/why-is-excel-file-opened-exclusively-by-another – Hadi Mar 30 '17 at 19:08
  • Thanks Hadi for the help. I appreciate it. Unfortunately, the link that is most similar to my problem is the first one and his solution was that he changed the path and forgot to change it back. The only other solution there was using process monitor to find if there is a lock. I have to contact someone else to do that since they took away our server access. The other solution is the proxy and correct me if I am wrong but it seems like when executing from the catalog it is executing as me (logging into SSMS with windows authentication). At least it shows me as the caller on the error report. – Scottdg Mar 30 '17 at 19:23
  • If you have the `sa` account try executing the package using [dtexec](https://technet.microsoft.com/en-us/library/ms162810(v=sql.105).aspx) using an sql authentication – Hadi Mar 30 '17 at 19:39
  • Else plz give me a feedback if you get the solution – Hadi Mar 30 '17 at 19:40
  • I can not run it with a SQL Server account. It must be run with a Windows Authentication account. I have seen several references to needing a proxy but I still don't understand that since it is executing with my account. Do you thin kit could have anything to do with the Excel file being on a remote share? I will modify my package and see if it works with the Excel file saved locally. – Scottdg Mar 30 '17 at 19:44
  • That worked. So it will not read the Excel file from a remote share. I suppose the proxy might fix that after all. – Scottdg Mar 30 '17 at 19:51
  • Happy to get things solved. If you find my answer helpful [accept it](http://www.stackoverflow.com/tour) else add your own answer – Hadi Mar 30 '17 at 19:53
0

I have faced same issue when I try with the existing SSIS dtsx packages on VS 2019.

Solution: I have removed existing OLEDB connections from the connection manager and created newly from the scratch. It resolved the issue.

-1

Using the built in excel connection manager in SSIS, the package needs to run in 32-bit mode. Switching this:

64BitRuntime option to FALSE

Only allows SSDT to run the package in 32bit mode, but it does not affect how it will run once you deploy it. To run it in 32bit mode from SSMS:

  • If you are right clicking on the package in the Integration Services Catalog and hitting execute, go to the advanced tab of the dialogue and check 32-bit runtime.
  • If you are executing it via a SQL Agent job. In the step, go to configuration > Advanced and check 32-bit runtime.
Mark Wojciechowicz
  • 4,287
  • 1
  • 17
  • 25