Win 2003 x64 - SSIS error Importing xls and access data

I am having a problem importing data from xls and access into my SQL2005 DB usingSSIS.Would appreciate any help in getting this resolved.

Environment:

Xeon 64 bit processor machine/Win 2003 64 bit (x64)/SQL 2005 64 bit

Some of the resources that I have dug up so far have pointed to Jet Engine SP8 and WOW64.

A search on the box shows this:

C:\Windows\SysWOW64\Msjet40.dll – File version is 4.0.9025.0

Not sure what is missing.

The following is the error from the import from xls. The one from access is very similar.

==================================================================================

Task Import abc_xls

Validation has started

[DTS.Pipeline] Information: Validation phase is beginning.

Progress: Validating - 0 percent complete

[Excel Source [1]] Error:The AcquireConnection method call to the connection manager "Excel Connection Manager" failed with error code 0xC0202009.

[DTS.Pipeline] Error:component "Excel Source" (1) failed validation and returned error code 0xC020801C.

Progress: Validating - 50 percent complete

[DTS.Pipeline] Error: One or more component failed validation.

Error: There were errors during task validation.

Validation is completed

[Connection manager "Excel Connection Manager"] Error:An OLE DB error has occurred. Error code: 0x80040154. An OLE DB record is available. Source: "Microsoft OLE DB Service Components" Hresult: 0x80040154 Description: "Class not registered".

[4073 byte] By [sql_rv] at [2007-12-19]
# 1
Directory C:\Windows\SysWOW64 is for 32-bit DLLs, so most likely you only have 32-bit Jet driver, but not 64-bit (I don't know if 64-bit driver exists at all. Hopefully someone else will comment on this). SSIS tries to load 64-bit driver, and since it is not registered on the system, you get this error.

Note that you may use 32-bit version of SSIS on this box, just run the package using 32-bit dtexec.exe from "Program Files (x86)" folder, instead of 64-bit dtexec.exe in "Program Files" folder.

MichaelEntinSSIS at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 2
There is no jet for excel and access on 64 bit and in actuality I don't believe there is much jet support in general on 64 bit.

Thanks,
Matt

MattDavid at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 3
There is only 1 DTexec.exe on this box. A search from c:\ on this box returns only this:
C:\Program Files\Microsoft SQL Server\90\DTS\Binn\DTExec.exe

There apparently is no "Program Files (x86)" folder. btw, when we initially tried installing SQL Server, we were unable to install anything other than SQL2005 64 bit (since the OS was 64 bit). This means no SQL 2000, and no SQL2005(32 bit).

If Jet is not available for 64 bit, it means we potentailly have to reinstall a 32 bit OS and start all over to have this working.

One of the workarounds (to avoid a complete rebuild) I can think of is importing the access/xls files to a 32 bit SQL on a different box and then DTS it over to this box.

Is there a better workaround that anyone has tried or can suggest? Thanks for all your responses. :)

Also, anyone has an idea if there is a roadmap for if/when Jet 64 for xls/access will be available?

sql_rv at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 4

My bad :(

There was in fact an x86 folder (I was just looking in the wrong box). So, using the dtexec on x86 works. Is there a way to have this scheduled other than to write a command scipt that invokes the x86\dtexec, and scheduling the command script?

Thanks!

sql_rv at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 5

I am new to SSIS. I also have a 64-bit implementation of SQL 2005. Can you explain how you use the x86\dtexec to run the import?

many thanks!

Summerstreet at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 6

OK! I found it. Thanks for the tip. Using NT scheduler works fine but if you want to keep all your sql jobs in one place then using the SQL Agent job scheduler is a better solution.

However you do it you are still invoking a command line option. Please correct me if you think I'm wrong but I think that whether it is a dtsrun equivalent or executing a batch/script job we still need to execute in a 32 bit environment so shelling out to the command line for execution is our only option.

Summerstreet at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 7
Summerstreet wrote:

OK! I found it. Thanks for the tip. Using NT scheduler works fine but if you want to keep all your sql jobs in one place then using the SQL Agent job scheduler is a better solution.

However you do it you are still invoking a command line option. Please correct me if you think I'm wrong but I think that whether it is a dtsrun equivalent or executing a batch/script job we still need to execute in a 32 bit environment so shelling out to the command line for execution is our only option.

You can easily run 32-bit DTEXEC.EXE from SQL Agent, just create 'Operating System (CmdExec)' step, provide path to 32-bit DTEXEC.EXE and command line arguments. You can use the same UI to help you build the command line agruments - create (temporary) SSIS step, provide all information, copy the command line arguments from Command Line tab page, paste them to the first (real) step, delete the temporary step.

MichaelEntinSSIS at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 8

Hello

Consider distributed queries through 32-bit server from Sql-task:
http://gorm-braarvig.blogspot.com/2005/11/access-database-from-sql-200564.html
...worked for me, anyway.

GormBraarvig at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 9

Even easier, go to your project properties in SSIS Designer. From there go to Configurations --> Debugging and set Run64BitRuntime to false.

Once I did this I was able to access and import data into an XLS file using SSIS on a machine running 64-bit SQL 2005.

Topple at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 10
Please let me know the exact command line you used showing the path of teh DTexec
chandrala at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 11

We used the following command and it worked beautifully.

C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe /f "C:\DEPLOYMENT\Control_Load_fact.dtsx" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING EW

DaveWu at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...

SQL Server

Site Classified