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

[mjustin]

Zitat von HolgerX:

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

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 von HolgerX:

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 von HolgerX:

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 von Uwe Raabe:

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.