Installierbares ISAM nicht gefunden

[Moony]

Hallo zusammen,

ich habe ein Programm umgeschrieben. Vorher lief jeglicher Datenbankzugriff über die ADO Komponente. Nun habe ich die Zugriffe gesplittet. Sprich ich habe für den Zugriff auf einen MS MSQL-Server die SDAC Komponente, für Oracle die ODAC-Komponente und für den Rest bleibt wie gehabt die ADO-Komponente.
Das Problem besteht darin, dass seitdem ich die Zugriffe gesplittet habe, ich zwar den Zugriff für eine Access Datenbank erstellen kann, aber wenn ich den Zugriff speichere und anschließend automatisch das Projekt wieder öffnen möchte, kommt die Fehlermeldung: "Installierbares ISAM nicht gefunden.". Ich speichere den ConnectionString aus der ADO Komponente und rufe dann diesen wieder auf.

An dem Source selber hat sich nichts geändert, es wurde lediglich eine Abfrage für die unterschiedlichen Zugriffe eingebaut.
Habe gelesen, dass dies am MDAC liegen könnte. Den habe ich überprüft und den aktuellsten drauf.

Ich hoffe ihr könnt mir da weiterhelfen.

Gruß, Moony

[Bernhard Geyer]

Wie schaut der Connection-String aus?

[Moony]

So sieht er aus nachdem alle Benutzerrelevanten Daten eingespflegt wurden:

'Provider=Microsoft.Jet.OLEDB.4.0;User ID=Admin;Data Source=C:\Programme\MeinProgram\Projects\Demo\Demo .mdb;Mode=Share Deny None;Extended Properties="";Jet OLEDB:System database="";Jet OLEDB:Registry Path="";Jet OLEDBatabase ";Jet OLEDB:Engine Type=5;Jet OLEDBatabase Locking Mode=1;Jet OLEDB:Global Partial Bulk Ops=2;Jet OLEDB:Global Bulk Transactions=1;Jet OLEDB:New Database ";Jet OLEDB:Create System Database=False;Jet OLEDB:Encrypt Database=False;Jet OLEDBon't Copy Locale on Compact=False;Jet OLEDB:Compact Without Replica Repair=False;Jet OLEDB:SFP=False'

[Bernhard Geyer]

ist auf jedenfall der richtige Provider für Access < V2007.

[Moony]

Aber irgendwas muß ja jetzt anders sein, obwohl ich schwören kann, dass sich der Source für diese Verbindung nicht geändert hat. Denn beim ersten Mal kann ich die Verbindung aufbauen. wenn ich dann aber über den genannten Connectionstring gehe, kommt die Fehlermeldung.

Gibt es denn eine Möglichkeit rauszufinden, was ihn stört?

[marabu]

Hi,

wenn die JET Treiber korrekt installiert sind, dann tippe ich auf die Extended Properties. Nimm den Eintrag mal ganz weg. Die massakrierten Password-Einträge hast ja wohl du beim posten verbrochen. Wie ist denn der ConnectionString entstanden? Generiert oder manuell?

Grüße vom marabu

[Moony]

Der ConnectionString wird zu Anfang über die Windows Datenbankeigenschaften zusammengebastelt. Sprich, es wird der Treiber ausgewählt, anschließend die Datenbank und die Benutzerdaten. Dieser Connectionstring wird beim Schließen der Verbindung in eine Datei gespeichert, jedoch ohne Benutzerdaten. Bei erneuten Öffnen der Quelle wird der Connectionstring aus der Datei gelesen und die benötigten Benutzerinformationen hinzugebastelt.

So hat es immer funktioniert. Erst nach der Erweiterung der unterschiedlichen Komponenten kommt zu solch einem Fehler.

[marabu]

Hallo,

da ist jetzt etwas Unschärfe hinein gekommen. Behauptest du, dass der abgebildete ConnectionString der ist, den dein Programm abspeichert, nachdem es die Credentials entfernt hat?

Zitat von marabu:

... Die massakrierten Password-Einträge hast ja wohl du beim posten verbrochen. ...

Beim Speichern musst du die beiden Password-Einträge vollständig entfernen und nicht verstümmeln. Ich würde aber lieber mit einer UDL-Datei arbeiten:

Delphi-Quellcode:

const
  CS 
    = 'FILE NAME="%s"'
    + ';User ID=%s'
    + ';Jet OLEDB:Database Password="%s"'
    ;
begin
  // ...
  with ADOConnection do
  begin
    ConnectString := Format(CS, [ChangeFileExt(ParamStr(0), '.udl'), UserId, Password]);
    //...
  end;
  // ...
end;

Freundliche Grüße

[Moony]

Hallo,

ich weiß jetzt nicht was du meinst mit den massakrierten Benutzerdaten???

Nachdem ich die Verbindung aufgebaut habe und dann irgendwann die Verbindung wieder trenne, wird der komplette Eintrag für
- User ID
- UID
- Password
- PWD

aus dem ConnectionString entfernt(Natürlich nur falls vorhanden). Anschließend wird der restliche ConnectionString in eine Datei gespeichert. Wenn die Verbindung wieder aufgebaut werden soll, wird der String aus der Datei gelesen und die Benutzerdaten hinzugefügt.

Deswegen wäre es nett, wenn du mir genau erläutern könntest, wo und was an dem ConnectionString nicht richtig sein soll? Er hat bis jetzt immer so einwandfrei funktioniert.

Gruß, Moony

[marabu]

Moin Moony,

vorneweg: Ein ADO ConnectionString besteht aus vom OLEDB Provider definierten name-value pairs, die durch ein Semikolon voneinander getrennt werden. Du kannst jeden Eintrag (name) mehrmals vorsehen, der jeweils letzte Eintrag überschreibt quasi alle anderen. Beim Connect wird der ConnectionString ausgewertet, normiert und vervollständigt. Danach kann er ganz anders aussehen als vorher.

Es ist nicht notwendig, dass du Einträge aus dem ConnectionString löschst um sie hinterher wieder einzufügen. Du kannst Einträge einfach hinten ansetzen, auch wenn sie bereits im String vorkommen.

Microsoft hat die Datenverknüpfung (Universal Data Link - UDL) als ADO Konfigurationsmöglichkeit geschaffen. So kannst du einen ConnectionString als Template hinterlegen und nur die anwendungsspezifischen Parameter ergänzen - siehe Beitrag #8.

Sobald du einen Parameternamen falsch schreibst, meldet der Jet OLEDB Provider den unsäglichen Fehler, den du beobachtet hast. In deinem Fall dürfte der Fehler gemeldet werden, weil du die Password-Parameter falsch behandelt hast. Dadurch entstehen undefinierte Parameterbezeichner. Also entweder richtig oder gar nicht:

Zitat von Moony:

So sieht er aus nachdem alle Benutzerrelevanten Daten eingespflegt wurden:

'Provider=Microsoft.Jet.OLEDB.4.0'
+ ';User ID=Admin'
+ ';Data Source=C:\Programme\MeinProgram\Projects\Demo\Demo .mdb'
+ ';Mode=Share Deny None'
+ ';Extended Properties=""'
+ ';Jet OLEDB:System database=""'
+ ';Jet OLEDB:Registry Path=""'
// + ';Jet OLEDB:Database "' // weg damit oder: ';Jet OLEDB:Database Password=""'
+ ';Jet OLEDB:Engine Type=5'
+ ';Jet OLEDB:Database Locking Mode=1'
+ ';Jet OLEDB:Global Partial Bulk Ops=2'
+ ';Jet OLEDB:Global Bulk Transactions=1'
// + ';Jet OLEDB:New Database "' // weg damit oder: ';Jet OLEDB:New Database Password=""'
+ ';Jet OLEDB:Create System Database=False'
+ ';Jet OLEDB:Encrypt Database=False'
+ ';Jet OLEDB:Don't Copy Locale on Compact=False'
+ ';Jet OLEDB:Compact Without Replica Repair=False'
+ ';Jet OLEDB:SFP=False'
;

Alles klar?

Wenn du keine UDL-Datei verwenden möchtest, dann vielleicht eine StringList (Delimiter := ';' QuoteChar := #0), deren Eigenschaften Values zum Setzen und Auslesen und DelimitedText als ConnectionString.

Freundliche Grüße