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

  • Thread starter Thread starter JimLad
  • Start date Start date
J

JimLad

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.'
 
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.
 
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.













- 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...
 
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
 
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.
 
3 quotes now come to mind:

/*> sorry for my previous post i found that there was an error in the

*/

//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.









- 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"";"

<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" />

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
 
Jim,

You have checked out all this?

http://www.connectionstrings.com/excel

Cor

3 quotes now come to mind:

/*> sorry for my previous post i found that there was an error in the

*/

//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.









- 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"";"

<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" />

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
 
Jim,

You have checked out all this?

http://www.connectionstrings.com/excel

Cor










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"";"

      <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" />

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- 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
 
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.






Jim,

You have checked out all this?

http://www.connectionstrings.com/excel

Cor










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"";"

<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" />

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- 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
 
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.













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- Hide quoted text -

- Show quoted text -

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
 
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. :<





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.













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- Hide quoted text -

- Show quoted text -

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
 
Back
Top