"Unerwarteter Fehler vom externen Datenbanktreiber (1)" beim Öffnen einer XLS-Datei

[mjustin]

Hallo,

in einem Delphi 2009 Projekt wird eine Excel-Datei über ADO geöffnet, gelesen und geschrieben. In der Vergangenheit lief dies in den VMWare Produktivumgebungen (Windows 7) und allen Entwicklungsumgebungen (Windows 7) problemlos.

Vermutlich durch ein Windows Update hat sich in den Office-Treibern auf den Entwicklungsrechnern etwas geändert, die Anwendung wirft die EOleException mit dem Text "Unerwarteter Fehler vom externen Datenbanktreiber (1)" sofort beim Öffnen der XLS-Datei. Wir können das in Frage kommende Windows Update vielleicht durch Deinstallationen der letzten Updates einkreisen, und müssen solange in den Produktivumgebungen auf Office-Updates verzichten.

Gibt es Möglichkeiten die Ursache des Fehlers weiter einzukreisen (ADO-Logging / Debugging)?

Ist es möglich, dazu ein Supportticket bei Embarcadero zu öffnen?

[TiGü]

Habt ihr mit dem Process Monitor das Problem untersucht?

[HolgerX]

Hmm..

Zeig mal deinen ConnectionString..

Embarcadero hat damit nichts zu tun, da es sich um eine Fehlermeldung des Treibers handelt!

Edit:
Und gib die Excel-Version vom Altsystem (Win7) und Neusystem an.

[mjustin]

Zitat:

Zitat von HolgerX (Beitrag 1385293)

Hmm..

Zeig mal deinen ConnectionString..

Embarcadero hat damit nichts zu tun, da es sich um eine Fehlermeldung des Treibers handelt!

Edit:
Und gib die Excel-Version vom Altsystem (Win7) und Neusystem an.

Der Connection String ist:

Delphi-Quellcode:

Provider=Microsoft.Jet.OLEDB.4.0;  Data Source=C:\Sandbox\***.xls;  Extended Properties="Excel 8.0;  HDR=YES;  IMEX=0"

Excel Version in den Entwicklungsumgebungen:
14.0.7188.5002 (32 Bit)

In der Produktionsumgebung:
14.0.7184.5000 (32 Bit)

[HolgerX]

Hmm..

Alternativ den Provider Microsoft.ACE.OLEDB.X.0 (Bei X die installierte Version, müsste bei dir 12 sein) verwenden anstelle von Microsoft.Jet.OLEDB.4.0.

[mjustin]

Zitat:

Zitat von HolgerX (Beitrag 1385297)

Hmm..

Alternativ den Provider Microsoft.ACE.OLEDB.X.0 (Bei X die installierte Version, müsste bei dir 12 sein) verwenden anstelle von Microsoft.Jet.OLEDB.4.0.

Ok, der Connection String beginnt nun mit

Code:

Provider=Microsoft.ACE.OLEDB.12.0;

Dann erscheint eine andere Fehlermeldung:

"Der Provider kann nicht gefunden werden. Möglicherweise ist der Provider nicht richtig installiert worden."

[jobo]

Den "unerwarteten Fehler" bei ADO kenne ich ganz gut, er taucht gerne bei Datumswerten mit Range Verletzung (erlaubten Range kenne ich nicht) auf. (Unabhängig von der Datenquelle, hier Excel)
Was scheinbar nach einem Fehler nach Windows Update aussieht, ist also vielleicht einfach Zufall (so wie mit der schwarzen Katze).

Mein Tipp: Exceldaten im Originalprogramm auf mögliche, außergewöhnliche Datumswerte prüfen. Das gilt besonders, wenn es sich um Handeingabedaten handelt oder zumindest manuell bearbeitet bzw. "korrigiert" (ein anderer Grund würde mir auch kaum einfallen, Excel als Importformat zu nutzen)

[mjustin]

Zitat:

Zitat von jobo (Beitrag 1385301)

Den "unerwarteten Fehler" bei ADO kenne ich ganz gut, er taucht gerne bei Datumswerten mit Range Verletzung (erlaubten Range kenne ich nicht) auf. (Unabhängig von der Datenquelle, hier Excel)
Was scheinbar nach einem Fehler nach Windows Update aussieht, ist also vielleicht einfach Zufall (so wie mit der schwarzen Katze).

Wir können einiges ausschliessen, da der Fehler auch dann auftritt, wenn wir alte Dateien und alte Programmversionen in der Entwicklungsumgebung testen, und in der Produktivumgebung diese Dateien fehlerfrei geöffnet werden können.

[HolgerX]

Zitat:

Zitat von mjustin (Beitrag 1385300)

Zitat:

Zitat von HolgerX (Beitrag 1385297)

Hmm..

Alternativ den Provider Microsoft.ACE.OLEDB.X.0 (Bei X die installierte Version, müsste bei dir 12 sein) verwenden anstelle von Microsoft.Jet.OLEDB.4.0.

Ok, der Connection String beginnt nun mit

Code:

Provider=Microsoft.ACE.OLEDB.12.0;

Dann erscheint eine andere Fehlermeldung:

"Der Provider kann nicht gefunden werden. Möglicherweise ist der Provider nicht richtig installiert worden."

Wie geschrieben, könnte es 12 sein, jedoch auch 14 oder 15 je nach installierter Office-Version.

[mjustin]

Zitat:

Zitat von HolgerX (Beitrag 1385303)

Zitat:

Zitat von mjustin (Beitrag 1385300)

Zitat:

Zitat von HolgerX (Beitrag 1385297)

Hmm..

Alternativ den Provider Microsoft.ACE.OLEDB.X.0 (Bei X die installierte Version, müsste bei dir 12 sein) verwenden anstelle von Microsoft.Jet.OLEDB.4.0.

Ok, der Connection String beginnt nun mit

Code:

Provider=Microsoft.ACE.OLEDB.12.0;

Dann erscheint eine andere Fehlermeldung:

"Der Provider kann nicht gefunden werden. Möglicherweise ist der Provider nicht richtig installiert worden."

Wie geschrieben, könnte es 12 sein, jedoch auch 14 oder 15 je nach installierter Office-Version.

Erst mal vielen Dank, wir schauen ob wir mit ACE ans Ziel kommen.

[mjustin]

Zitat:

Zitat von HolgerX (Beitrag 1385303)

Wie geschrieben, könnte es 12 sein, jedoch auch 14 oder 15 je nach installierter Office-Version.

Ist bei Excel 2010 der ACE OLEDB Treiber bereits standardmäßig enthalten oder muss er nachinstalliert werden?


Nach diesen Artikel ist es etwas unklar, er sagt "you should install this manually":

Zitat:

Now we have a new guy in the town. Let me introduce it : "Microsoft ACE OLEDB Provider". It's "ProgID" (in terms of COM/OLEDB) is "Microsoft.ACE.OLEDB.12". It does not come within the OS, you should install this manually by downloading it from here . The name of the download is "Microsoft Access Database Engine 2010 Redistributable" as this 64bit ACE OLEDB Provider is the result of our Office 2010. It has been around in the scene with Office 2007 but it was available as 32bit only.

https://www.gbhost.in/knowledgebase/...CEOLEDB12.html

[HolgerX]

Hmm..

Zu mindestens ab Office 2010 wird der ACE OLEDB Treiber mit installiert..
Es gibt hier jedoch (irgendwo gelesen) unterschiedliche Versionen für 32Bit und 64 Bit und natürlich je Office-Version...

Bei mit mit Office 2013 32Bit ist es der 15er.

[mjustin]

Update:

in einer weiteren Entwicklungsumgebung ist eine ältere 64 Bit Version von Excel 2010 installiert, hier tritt der Fehler ebenfalls auf:

Excel Version in den Entwicklungsumgebungen (in diesen tritt der Fehler auf):
14.0.7128.5000 (64 Bit)
14.0.7188.5002 (32 Bit)

In der Produktionsumgebung:
14.0.7184.5000 (32 Bit)

Die Excel-Version in der Produktionsumgebung liegt "zwischen" denen der Entwicklungsumgebungen. Nur in der Produktionsumgebung tritt der Fehler nicht auf.

[HolgerX]

Hmm..

Hab da mal was aus einem Testtool herausgenommen:

Delphi-Quellcode:

uses
  ADODB;

const
  c_JetOleDB = 'Microsoft.Jet.OLEDB.4.0';
  c_ACEOleDB = 'Microsoft.ACE.OLEDB';


procedure GetADOProviderNames(AProviderList : TStrings);
begin
  AProviderList.Clear;
  GetProviderNames(AProviderList);
end;

function GetSQLServerProvider: string;
var
  tmpProviderList : TStringList;
  i : integer;
begin
  Result := '';
  tmpProviderList := TStringList.Create;
  try
    GetADOProviderNames(tmpProviderList);
    tmpProviderList.Sort;

    if tmpProviderList.IndexOf(c_JetOleDB) > -1 then
      Result := c_JetOleDB;

    for i := 0 to tmpProviderList.Count -1 do begin
      if Pos(c_ACEOleDB, tmpProviderList[i]) = 1 then
        Result := tmpProviderList[i];
    end;

  finally
    tmpProviderList.Free;
  end;
end;


procedure OpenExcelFile(ADOConnectionExcel : TADOConnection; AExcelFile : string; AWithHeader : boolean);
var
  tmpProvider : string;
  tmpProperties : string;
  tmpExcel : string;
  tmpHeader : string;
  tmpPWString : string;
  tmpExt : string;
begin
  ADOConnectionExcel.Close;

  tmpExt := LowerCase(ExtractFileExt(AExcelFile));
  tmpExcel := '';
  if tmpExt = '.xls'  then tmpExcel := 'Excel 8.0';
  if tmpExt = '.xlsx' then tmpExcel := 'Excel 12.0 Xml';
  if tmpExt = '.xlsm' then tmpExcel := 'Excel 12.0 Macro';
  if tmpExt = '.xlsb' then tmpExcel := 'Excel 12.0';

  if tmpExcel = '' then begin
    ShowMessage('Invalid FileExt!');
    exit;
  end;

  if AWithHeader  then
    tmpHeader := 'HDR=YES'
  else
    tmpHeader := 'HDR=NO';

  tmpProperties := 'Extended Properties="' + tmpExcel + ';' + tmpHeader + ';IMEX=1";';

  // Kein Passwort setzen (Ja, auch bei ACE ist die Property mit 'Jet OLEDB:')
  tmpPWString := 'Jet OLEDB:Database Password="";';

  tmpProvider := GetSQLServerProvider;
  ADOConnectionExcel.ConnectionString := 'Provider='+tmpProvider+';' + tmpProperties + tmpPWString + 'Data Source=' + AExcelFile;
  ADOConnectionExcel.Open;
end;

Hiermit wird anhand der Extension und der installierten ACE-Version der Connection-String dynamisch zusammen gesetzt.

Es wird immer die höchste ACE-Version verwendet, auch wenn mehrere installiert wurden, selbst, wenn aufgrund der Office-Version noch JET verwendet werden könnte.

[jobo]

Um die Möglichkeiten noch etwas auszuweiten:
Habt Ihr mal mit unterschiedlichen Exceldatei-Formaten probiert?
Neben der reinen Fehlersuche habt ihr ja vielleicht die Möglichkeit, ein bestimmtes Format zu wählen (oder spätestens vor Datenzugriff zu konvertieren) und damit dem Problem aus dem Weg zu gehen.
Was mir noch einfällt sind die Undo Daten in Office Dateien. Einfach mal probieren, etwas aufzuräumen. Da sich viele Updates ja neuerdings um Security drehen, könnte an der Ecke was geschehen sein.

[mjustin]

Zitat:

Zitat von HolgerX (Beitrag 1385311)

Hmm..

Zu mindestens ab Office 2010 wird der ACE OLEDB Treiber mit installiert..
Es gibt hier jedoch (irgendwo gelesen) unterschiedliche Versionen für 32Bit und 64 Bit und natürlich je Office-Version...

Bei mit mit Office 2013 32Bit ist es der 15er.

Man muss vermutlich für Delphi 2009 (32 Bit) dann Excel 32 Bit installieren, wenn man über ACE OLEDB auf Excel-Dateien zugreifen will?

[mjustin]

Zitat:

Zitat von HolgerX (Beitrag 1385316)

Hab da mal was aus einem Testtool herausgenommen:

Herzlichen Dank dafür! In der Registry fand ich auch die Nummer der installierten Version für ACE, damit bin ich mit etwas Glück auch einen Schritt in Richtung Workaround.

[mjustin]

Zitat:

Zitat von HolgerX (Beitrag 1385316)

Hiermit wird anhand der Extension und der installierten ACE-Version der Connection-String dynamisch zusammen gesetzt.

Das funktioniert hier schon mal soweit, der Connectionstring ist nun

Code:

Provider=Microsoft.ACE.OLEDB.12.0; Data Source=C:\Sandbox\***.xls; Extended Properties="Excel 8.0; HDR=YES; IMEX=0"

Nun erscheint beim Start eine neue Fehlermeldung:

Code:

"Installierbares ISAM nicht gefunden"

Umgebung ist Windows 7 64 Bit, Excel 2010 32 Bit, mit OLEDB ACE 32 Bit.

[Uwe Raabe]

Das Problem scheint auch anderweitig bekannt zu sein: Excel Import u. Export - Unerwarteter Fehler vom externen Datenbanktreiber

[mjustin]

Zitat:

Zitat von Uwe Raabe (Beitrag 1385342)

Das Problem scheint auch anderweitig bekannt zu sein: Excel Import u. Export - Unerwarteter Fehler vom externen Datenbanktreiber

Wunderbar, vielen Dank! Die Lösung funktioniert wie dort für Windows 7 beschrieben (Deinstallation zweier Updates).

Wir müssen nun schauen ob wir das Problem nur durch Sperren der beiden Updates vermeiden können, oder ob es bessere Lösungen gibt die mit Delphi 2009 funktionieren. Da die XLS Dateien von externen Partnern kommen, ist eine Umstellung auf XLSX oder andere Formate aktuell nicht abzusehen.

[Uwe Raabe]

Vielleicht bringt dir dieser Thread noch was: ADO after KB4041681

[jobo]

Zitat:

Zitat von mjustin (Beitrag 1385358)

Da die XLS Dateien von externen Partnern kommen, ist eine Umstellung auf XLSX oder andere Formate aktuell nicht abzusehen.

Wie gesagt, man könnte die Datei vor dem Import konvertieren. Z.B. via Com Server mittels Excel selbst oder mit Bibliotheken, die natürlich ohne ADO die Daten auslesen.

[mjustin]

Zitat:

Zitat von Uwe Raabe (Beitrag 1385360)

Vielleicht bringt dir dieser Thread noch was: ADO after KB4041681

Danke! Darin wird auch auf https://social.msdn.microsoft.com/Fo...=sqldataaccess verlinkt, darin wiederum wird der Fehler "Could not find installable ISAM." berichtet, der bei alten Excel Dateien un Verwendung von ACE OLEDB auftritt. Daher könnte es auch den von mir festgestellten ISAM Fehler erklären.

Auch ist ein offizielles Statement enthalten:

Zitat:

** Official Update **

We have created a statement on this issue in the following link:

https://blogs.msdn.microsoft.com/dat...urity-updates/

As a further update, the Office product team has agreed to look into this to work towards a solution. That said, please still note that the JET provider has been deprecated for 15 years, and we still recommend switching to the ACE provider or the SSIS Excel connector.

Thank you all again for providing the workaround you have found and shared with the rest of the community.

I will be deleting my earlier comments to help avoid confusion.

~Chrone with Microsoft SQL Support~

(Not a forum moderator)

Im verlinkten Artikel wird darauf aufmerksam gemacht, dass Jet seit dem Jahr 2000 "deprecated" ist:

When looking into this issue, the largest thing to note is: The JET provider has been deprecated as of 2002. The last changes were made to this in 2000.

Empfohlen wird: "Use Microsoft.ACE.OLEDB.12.0 or Microsoft.ACE.OLEDB.16.0"

Update: die aktuelle Version ACE OLEDB (2016) zeigt nicht den "ISAM" Fehler, den man bei der 2010er Version erhielt. Für die Jet->ACE Umstellung müssen die Feldkomponenten aktualisiert werden (WideString wird zu WideMemo), aber das ist für eine kleine Anwendung überschaubarer Aufwand.

[kompi]

Angeblich hat Microsoft dieses Problem mit dem heutigen Update (KB 4048954), zumindest für Windows 10, behoben.

Gruß Kompi

[mjustin]

Zitat:

Zitat von kompi (Beitrag 1386334)

Angeblich hat Microsoft dieses Problem mit dem heutigen Update (KB 4048954), zumindest für Windows 10, behoben.

Gruß Kompi

Ja, der Blog Eintrag unter https://blogs.msdn.microsoft.com/dat...urity-updates/ wurde aktualisiert und die unterstützten Versionen aufgelistet, darunter auch Windows 7.

In der VMWare Umgebung nutzen wir nun den empfohlenen neueren ACE OLEDB Treiber für den Excel-Zugriff und es funktioniert problemlos, lediglich manche Felder mussten von WideStringField auf WideMemoField umgestellt werden.

Danke für den Hinweis!