EXCEL Connection in a x64 system

[GrandMauler]

I'm having difficulty running a with my package because it requires reading data from an Excel file.

so this means there is an EXCEL connection at design time.

But I get this message:

[Connection manager "Excel Connection Manager"] Error: SSIS Error Code DTS_E_OLEDBERROR.
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".



From what I'm seeing on the web, there is no way to run this except in a x86 environment?

Please tell me I'm wrong.

 

[GrandMauler]

Actually, i have the answer... sort of..

In the properties page for the overall SSIS solution, simply set the Run64BitRunTime = False.


Which sucks, because the idea was to optimize for a x64 system... but, what the hell.... if it works, it works.


Anyway, if anyone has a better answer, please share.

 

[SemperFiDownUnda]

I've got a similar problem and thought this would solve it. I'm trying to pull in data from and Access database.

Works ok in VS, works ok in MS SQL Server Management Studio, fails when that same package is defined as a step in a SQL Server Agent job.

Run64BitRunTime = False seems to be ignored by SQL Server agent when it executes the step.

Hope I've been helpful,
Wayne Francis

If you want to get the best response to a question, please check out FAQ222-2244 first

 

[AlexCuse]

This sounds like a permissions issue to me. Does the sql server agent have all the same rights as your login does? (I apologize if you already checked that).

I can't imagine that the SQL Server Agent picks and chooses what package properties to pay attention to. Bob help us all if it does ;-)

Hope this helps,

Alex

[small]----signature below----[/small]
I don't do any programming whatsoever

Ignorance of certain subjects is a great part of wisdom

 

[MDXer]

The issue has to do with the Driver. The JET Drivers are 32 bit and currently not available in a 64bit version.

[URL unfurl="true"]http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=167907&SiteID=1[/url]

Paul
---------------------------------------
Shoot Me! Shoot Me NOW!!!
- Daffy Duck

 

[SemperFiDownUnda]

AlexCuse thanks for the suggestion. The SQL Server Agent account is Network Service and it is both a Sysadmin on all our instances and a member of the administration group on the box. Don't see why it would have a problem there.

MDXer, Thanks for the link. I've already read that post and tried it but our enterprise installation did not actually create a DTS folder in C:\Program Files (x86)\Microsoft SQL Server\90\

On our server there is only 1 DTExec.exe and that seems to be the 64 bit version.

I tried to impliment the solution outlined in thread1555-1264274 but we are not allowed to create proxy accounts on this box (politics).

I'm really at my wits end trying to get access data imported into SQL 2005 (64) in a automated fashion. Management will not go for spending money on purchasing a 32 bit SQL 2005 box just for pulling in data from access and I agree that it isn't a good option.

Any help you can provide would be welcomed.

Thanks in advance
Wayne

Hope I've been helpful,
Wayne Francis

If you want to get the best response to a question, please check out FAQ222-2244 first

 

[Flybridge]

According to ssis.wik.is

'Both JET and ACE providers are 32-bit only, and thus can be supported natively on 32-bit platforms and using WOW64 mode on IA-64 and x86-64. In order to use Jet and Ace providers in 64-bit platforms, 32-bit version of dtexec.exe must be invoked. For more information on connectors and 64-bit considerations, please see the artcile on 64-bit story. (64-bit Story)'

This is the link for the 64-bit story.

http://ssis.wik.is/64-bit_Story

Hope this helps.

'The world isn't round - it's bent!' Spike Milligan