unbekannter Fehler beim Zugriff auf Exceldatei aus einer Dll

[v2afrank]

Ich habe hier eine Dll, in der ich auf eine Exceldatei zugreife. Jetzt ist mir aufgefallen, dass ab und zu folgender Fehler kommt:EOleException Unbekannter Fehler.
Ich habe das ganze mal in eine Testdll zusammengefasst, die ich 5000 mal hintereinander aufrufe. Das ganze habe ich einmal auf einem Windows 7 Rechner und auf einem Vista Rechner laufen lassen. Das Ergebnis ist ganz interessant. Manchmal kommt das Testprogramm durch, manchmal bekomme ich den unbekannten Fehler nach ca. 100 Durchläufen. Auf dem Windows 7 Rechner scheint der Fehler weniger häufig zu passieren, er tritt hier aber auch auf.
Hier der Code der Dll:

Delphi-Quellcode:

library DllTest;

{ Wichtiger Hinweis zur DLL-Speicherverwaltung: ShareMem muss sich in der
  ersten Unit der unit-Klausel der Bibliothek und des Projekts befinden (Projekt-
  Quelltext anzeigen), falls die DLL Prozeduren oder Funktionen exportiert, die
  Strings als Parameter oder Funktionsergebnisse übergeben. Das gilt für alle
  Strings, die von oder an die DLL übergeben werden -- sogar für diejenigen, die
  sich in Records und Klassen befinden. Sharemem ist die Schnittstellen-Unit zur
  Verwaltungs-DLL für gemeinsame Speicherzugriffe, BORLNDMM.DLL.
  Um die Verwendung von BORLNDMM.DLL zu vermeiden, können Sie String-
  Informationen als PChar- oder ShortString-Parameter übergeben. }


uses
  SysUtils,
  Classes,
  DB, ADODB;

{$R *.res}

 procedure ExportExcelListe(ExcelDatei:Shortstring;Arbeitsblatt:Shortstring;
                            Spalte:Shortstring);
 var
  ADOConnection : TADOConnection;
  ADOQuery : TADOQuery;
  begin
ADOConnection := TADOConnection.Create(nil);
ADOConnection.LoginPrompt := False;
ADOConnection.ConnectionString := 'Provider=Microsoft.Jet.OLEDB.4.0; Data Source=' + ExcelDatei + ';Extended Properties=Excel 8.0';
ADOQuery := TADOQuery.Create(nil);
ADOQuery.Connection := ADOConnection;
ADOQuery.SQL.Text := 'Select '+Spalte+' from ' + Arbeitsblatt + '';
ADOQuery.Open;
ADOQuery.Close;
ADOConnection.Close;
ADOQuery.Free;
ADOConnection.Free;
  end;


 exports
  ExportExcelListe;
begin

end.

Und der Code wie ich die Dll teste:

Delphi-Quellcode:

unit Fuchstest;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TForm7 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form7: TForm7;

 procedure ExportExcelListe(ExcelDatei:Shortstring;
                            Arbeitsblatt:Shortstring;
                            Spalte:Shortstring  );external 'DllTest.dll';
implementation

{$R *.dfm}

procedure TForm7.Button1Click(Sender: TObject);
var n:Integer;
begin
 for n := 1 to 5000 - 1 do
   begin
   caption:=inttostr(n);
   Application.ProcessMessages;
 ExportExcelListe('c:\Ressourcen.xls',
  '[Texte$]',
 'Deutsch');
   end;
end;

end.

Das ganze habe ich mit Delphi 2010 kompiliert

[p80286]

Zitat von v2afrank:

Delphi-Quellcode:

 ExportExcelListe('c:\Ressourcen.xls',
  '[Texte$]',
 'Deutsch');

das fällt mir auf den ersten Blick auf. Seit XP hat eigentlich niemand (Benutzer) etwas im RootDirectory zu suchen.

Versuch es doch mal mit "C:\temp\Ressourcen.xls"

Gruß
K-H

[v2afrank]

In der eigentlichen Anwendung ist die Dateim im Dokumenteverzeichnis des Users. Ich habe es nur zu Testzwecken nach C:\ kopiert, da ich zu faul war den kompletten Pfad auf dem zweiten Rechner anzulegen.

Ich habe das ganze mitlerweile auch mal in ein Programm (also ohne Dll)gepackt, das Ergebnis ist aber das gleiche

[Bernhard Geyer]

Guck dir mal den Ressourcenverbrauch von Windows/deines Programmes an. Ich tipp mal darauf das irgendwo Speicher/Ressourcen verloren werden und das irgendwann mal Windows für deinen Prozess *dicht* macht und keine weiteren mehr zuteilt.

Exceldateien würde ich direkt per COM/Automatisierung lesen und ADO/JET/Access außen vorlassen. Über den ADO-Weg gibt es öfters Probleme

[v2afrank]

Der Speicher steigt schon leicht an. Ich befürchte aber, dass mir nichts anderes übrig bleibt als auf einer anderen Art die Daten auszulesen. So ist das ganze zu heikel.

[omata]

Ruf doch mal Coinitialize im Initialisierungsbereich der DLL auf.

[v2afrank]

Habe ich gemacht und nach einigen Versuchen den Fehler wieder bekommen