ISAM error related to Excel 2003 Jet Engine on Server 2003 SP2

JimLad

unread,

Apr 16, 2009, 12:59:24 PM4/16/09

to

Hi,

We've just tried to release an app that uses JET to access data on
Excel 2003. Unfortunately we've discovered that our test server was at
SP1 and the live server is SP2 (I know - duh!). Any way we're getting
the standard 'Could not find installable ISAM' message.

Having looked into it the problem seems to be the value of the
following registry key:
HKLM\Software\Microsoft\Jet\4.0\Engines\Excel\win32

The old SP1 working value is: C:\WINDOWS\system32\msexcl40.dll
The new SP2 value that doesn't work: C:\Program Files\Microsoft Office
\OFFICE11\msaexp30.dll

Now we could swap back to the old value, but I've read that starting
Access 2003 will swap the value back again.

Can anyone confirm if there is a reliable fix for this?

Cheers,

James

Paul Clement (MVP) wrote the following in March 2007, but didn't
follow it up:

'It looks like Microsoft disabled the Access to Excel linking
technology in Office 2003 SP2 because of a court decision based upon a
long running patent infringement lawsuit:

http://news.com.com/Patent+ruling+costs+Microsoft+8.9+million/2100-1007_3-5735432.html
http://support.microsoft.com/?id=904953

Unfortunately, the method they chose to do this (which is rather
cheesy if you ask me) also broke the data access technology which
relies on the same ISAM driver method. They have configured Microsoft
Access to update the ISAM reference to point to the expression
evaluator library (which of course is invalid when using the Jet
library).

I will check to see if there is a workaround for this. You could
probably create a simple script that changes the registry entry to
enable data access support for Excel but that may not be the best
solution.'

sloan

unread,

Apr 16, 2009, 1:48:57 PM4/16/09

to

90% of the time when I get this message:

'Could not find installable ISAM' message

it means the connection string is flawed somehow.

Post your TestServer connection string and your ProductionServer connection
string.

A space in the filename, a missing single quote...any of them can kill you.

You have to SUPER ANALLY examine your connection string.

"JimLad" <james...@yahoo.co.uk> wrote in message
news:94a6377f-7136-4943...@f19g2000yqh.googlegroups.com...

JimLad

unread,

Apr 16, 2009, 4:29:43 PM4/16/09

to

On Apr 16, 6:48 pm, "sloan" <sl...@ipass.net> wrote:
> 90% of the time when I get this message:
> 'Could not find installable ISAM' message
>
> it means the connection string is flawed somehow.
>
> Post your TestServer connection string and your ProductionServer connection
> string.
>
> A space in the filename, a missing single quote...any of them can kill you.
>
> You have to SUPER ANALLY examine your connection string.
>

> "JimLad" <jamesdbi...@yahoo.co.uk> wrote in message

>
> news:94a6377f-7136-4943...@f19g2000yqh.googlegroups.com...
>
>
>
> > Hi,
>
> > We've just tried to release an app that uses JET to access data on
> > Excel 2003. Unfortunately we've discovered that our test server was at
> > SP1 and the live server is SP2 (I know - duh!). Any way we're getting
> > the standard 'Could not find installable ISAM' message.
>
> > Having looked into it the problem seems to be the value of the
> > following registry key:
> > HKLM\Software\Microsoft\Jet\4.0\Engines\Excel\win32
>
> > The old SP1 working value is: C:\WINDOWS\system32\msexcl40.dll
> > The new SP2 value that doesn't work: C:\Program Files\Microsoft Office
> > \OFFICE11\msaexp30.dll
>
> > Now we could swap back to the old value, but I've read that starting
> > Access 2003 will swap the value back again.
>
> > Can anyone confirm if there is a reliable fix for this?
>
> > Cheers,
>
> > James
>
> > Paul Clement (MVP) wrote the following in March 2007, but didn't
> > follow it up:
>
> > 'It looks like Microsoft disabled the Access to Excel linking
> > technology in Office 2003 SP2 because of a court decision based upon a
> > long running patent infringement lawsuit:
>

> >http://news.com.com/Patent+ruling+costs+Microsoft+8.9+million/2100-10...

> >http://support.microsoft.com/?id=904953
>
> > Unfortunately, the method they chose to do this (which is rather
> > cheesy if you ask me) also broke the data access technology which
> > relies on the same ISAM driver method. They have configured Microsoft
> > Access to update the ISAM reference to point to the expression
> > evaluator library (which of course is invalid when using the Jet
> > library).
>
> > I will check to see if there is a workaround for this. You could
> > probably create a simple script that changes the registry entry to
> > enable data access support for Excel but that may not be the best

> > solution.'- Hide quoted text -
>
> - Show quoted text -

Definitely not the connection string. As stated it's a problem that
Paul Clement spotted a couple of years ago. I am well aware of the
connectionstring issues but this is one of the 1% cases that isn't
related to that...

Cor Ligthert[MVP]

unread,

Apr 17, 2009, 2:36:36 AM4/17/09

to

Jim,

In this long forum discussion about this, there is called a solution, it is
like this.
\\\
hello friends,

sorry for my previous post i found that there was an error in the connection
string ie excel8.0 instead of excel 8.0

that make the problem.

Regards

Prathap

///

Cor

sloan

unread,

Apr 17, 2009, 9:51:17 AM4/17/09

to

3 quotes now come to mind:

/*

> sorry for my previous post i found that there was an error in the
> connection string ie excel8.0 instead of excel 8.0

*/

//Quote

A space in the filename, a missing single quote...any of them can kill you.
You have to SUPER ANALLY examine your connection string.

//End Quote

//
Definitely not the connection string.//

That's why I asked for you to post the actual connection string(s).
If you're seeking help, then that would have been a simple thing to do.

Good luck dude.

"Cor Ligthert[MVP]" <Notmyfi...@planet.nl> wrote in message
news:%23wZgiby...@TK2MSFTNGP03.phx.gbl...

JimLad

unread,

Apr 20, 2009, 5:27:05 AM4/20/09

to

On Apr 17, 2:51 pm, "sloan" <sl...@ipass.net> wrote:
> 3 quotes now come to mind:
>
> /*> sorry for my previous post i found that there was an error in the
> > connection string ie excel8.0 instead of excel 8.0
>
> */
>
> //Quote
> A space in the filename, a missing single quote...any of them can kill you.
> You have to SUPER ANALLY examine your connection string.
> //End Quote
>
> //
> Definitely not the connection string.//
>
> That's why I asked for you to post the actual connection string(s).
> If you're seeking help, then that would have been a simple thing to do.
>
> Good luck dude.
>

> "Cor Ligthert[MVP]" <Notmyfirstn...@planet.nl> wrote in message

>
> news:%23wZgiby...@TK2MSFTNGP03.phx.gbl...
>
>
>
> > Jim,
>
> > In this long forum discussion about this, there is called a solution, it
> > is like this.
> > \\\
> > hello friends,
>
> > sorry for my previous post i found that there was an error in the
> > connection string ie excel8.0 instead of excel 8.0
>
> > that make the problem.
>
> > Regards
>
> > Prathap
>
> > ///
>

> > Cor- Hide quoted text -

>
> - Show quoted text -

Hi,

We have tried several connection strings - all work on our dev
machine, but not on live:

_connectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=TestData1.xls;Extended Properties=""Excel 8.0;IMEX=1"";"

We have tried single quotes and doubles quotes on the extended
properties. We have also proved that reverting the registry key fixes
the problem.

Another point to note is that we don't have the win32old registry key
on the live server.

Any help would be great. I still don't think it's the
connnectionstring that's the problem, but I will try anything that
people mention...

James

Cor Ligthert[MVP]

unread,

Apr 20, 2009, 5:56:49 AM4/20/09

to

Jim,

You have checked out all this?

http://www.connectionstrings.com/excel

Cor

"JimLad" <james...@yahoo.co.uk> wrote in message

news:7ca8a3dc-2357-4a73...@z14g2000yqa.googlegroups.com...

JimLad

unread,

Apr 20, 2009, 8:38:34 AM4/20/09

to

On Apr 20, 10:56 am, "Cor Ligthert[MVP]" <Notmyfirstn...@planet.nl>
wrote:

> Jim,
>
> You have checked out all this?
>
> http://www.connectionstrings.com/excel
>
> Cor
>

> "JimLad" <jamesdbi...@yahoo.co.uk> wrote in message

> James- Hide quoted text -

>
> - Show quoted text -

Sticking OLEDB; on the front didn't work anywhere.

Sticking in HDR=Yes; as opposed to just letting it default, did not
made a difference.

Any other ideas?

James

sloan

unread,

Apr 20, 2009, 9:50:12 AM4/20/09

to

Have you put single quotes around the filename?

Please post your EXACT connection string...without substitutes like
FILE_PATH

You can change it slightly if you don't want us to know your folder
structure.

c:\super secret area\personal1.xls

c:\my folder\file1.xls

But you need to keep the spaces in the folder names and give a clear
alternate version of your filename.

"JimLad" <james...@yahoo.co.uk> wrote in message

news:b323896b-c980-44ab...@q19g2000vbn.googlegroups.com...

JimLad

unread,

Apr 20, 2009, 10:36:21 AM4/20/09

to

On Apr 20, 2:50 pm, "sloan" <sl...@ipass.net> wrote:
> Have you put single quotes around the filename?
>
> <add name="ExcelConnectionString"
> connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data
> Source=FILE_PATH;Extended Properties='Excel 8.0;IMEX=1'"
> providerName="System.Data.OleDb" />
>
> Please post your EXACT connection string...without substitutes like
> FILE_PATH
>
> You can change it slightly if you don't want us to know your folder
> structure.
>
> c:\super secret area\personal1.xls
>
> c:\my folder\file1.xls
>
> But you need to keep the spaces in the folder names and give a clear
> alternate version of your filename.
>

Hi,

The filename has no path just the name of the file 'testfile.xls'. No,
we never tried quotes round it. It works fine when we change the reg
key value.

The fix we're going to use is to change the value of the reg key:

HKLM\Software\Microsoft\Jet\4.0\Engines\Excel\win32

from the non-working:
C:\Program Files\Microsoft Office\OFFICE11\msaexp30.dll (N.B. this
file doesn't even exist on our servers!)
back to:
C:\WINDOWS\system32\msexcl40.dll

This is known to work. We've now found that Access 2003 isn't
installed so there is no danger of Access changing the value back
again.
We've now installed SP2 on our test server but the reg value didn't
change so we're at a bit of a loss as to how the value got changed -
our current assumption is that at some point Access 2003 was installed
on the production server, but has subsequently been uninstalled.
We won't be creating a win32old value.

Please note that if you have Access 2003 installed I don't recommend
this fix as running Access 2003 is reported to change the reg key back
to the non-working version again. You could try creating a win32old
key containing the correct path - from snippets of other posts it
sounds like that might work as well and have the benefit of allowing
Access 2003 to be run - but I haven't tested it.

Cheers,

James

sloan

unread,

Apr 20, 2009, 11:23:46 AM4/20/09

to

Thanks for posting the lengthy solution.

//our current assumption is that at some point Access 2003 was installed
on the production server, but has subsequently been uninstalled.//

That seems to be the best theory.

You're right dude. That one was a real stinker. :<

"JimLad" <james...@yahoo.co.uk> wrote in message

news:8ea9b0b7-a942-4447...@l5g2000vbc.googlegroups.com...