Adoconnection liest keinen String

[Privateer3000]

Hallöchen allerseits,
ich habe ein seltsames Problem.
Seit langem setze ich nun schon Ado mit Access ein.
Nun mit einem neuen Projekt tauchen Probleme auf die ich noch nie hatte.
Zum Projekt:
für die Connection nehme ich eine DatenmodulUnit mit AdoConnection.
Auf dem Hauptformular stelle ich die Verbindung her,
gespeichert und abgerufen wird der Connectionstring in der Registry.
Bisher noch nie ein Problem.
Wenn nun die Anwendung auf einem anderen Rechner ausgeführt
und sich damit der String ändert wird zwar aufgefordert die Konfiguration
neu einzugeben ! die gespeichert wird ! kommt es zu keinem Connect.
Es wird immer auf den ursprünglichen String zurückgegriffen der bei der
Entwicklung in der Adoconnection stand.
Selbst wenn ich den String leere und neu compiliere kommt ein Authentifizierungsfehler
beim Start der Anwendung.
Fordere ich während der Laufzeit den Connect an (Opendatabase) kommt ein True zurück.
Aber arbeiten mit der Db tut es trotzdem nicht -> Fehler bei der Authentifizierung!
Beim nächsten Start der Anwendung beginnt das Spiel von vorne.
Der Registry Eintrag ist völlig korrekt.
Beim Formshow wird der Registryeintrag gelesen aber nicht von der Adoconnection benutzt,
so denke ich jedenfalls.
Hat jemand eine Idee dazu

Grüße

[Bummi]

Hast Du mal mit dem Debugger durchgesteppt ?
2 Stellen als Einstieg, BeforeConnect und das Setzen den ConnectionStrings

[Privateer3000]

In der Entwicklungsumgebung funktioniert es doch.
Da kann ich den Fehler nicht nachvollziehen.
Wenn ich jedoch den String leere,
knallt es beim ersten query.
Obwohl beim Anwendungsstart :

Delphi-Quellcode:

if ReadDSNFromRegistry(DSN)=true then begin
 if DataModule1.SetMinervaDSN(DSN)=true then

mittels SetMinervaDSN die Adoconnection den String (DSN) setzen müsste.

Delphi-Quellcode:

SetMinervaDSN:=true;
if Datenbank.Connected=true then
if CloseDatabase=false then begin
SetMinervaDSN:=false;
Exit;
end;
Datenbank.ConnectionString:=DSN;

DSN habe ich geprüft und anzeigen lassen.Alles OK.
Aber langsam nähern wir uns dem Problem.

Danke für deine Antwort!

[jobo]

Hast Du irgendwo eine Leiche im Keller?
Irgendein ADOQuery oder ähnliche, die ja eigene Connectionstrings halten können?
In Kombi mit DesignTime Active=True und gespeichertem PW läuft es bei dir und auf dem anderen Rechner nicht (kein zugriff auf die MDB..?)
Die Access MDB sollte natürlich auch via Netzlaufwerk identisch erreichbar sein. MSAccess Security, die bei Dir passend eingerichtet ist, bei dem anderen System aber nicht, wäre auch ne Idee...

[Privateer3000]

Die gleiche Idee hatte ich auch schon
aber nein leider nicht.
Alles Querys sind "sauber".

[Bummi]

Warum nicht einfach

Delphi-Quellcode:

if ReadDSNFromRegistry(DSN) then 
  begin
    AdoConnection.Connected := false;
    AdoConnection.ConnectionString:= DNS;
    AdoConnection.Connected := true; 
  end else Messagedlg('FEHLER',mtError,[mbok],0);

[p80286]

Leicht OT:
Irgendwer hat hier vor ein paar Monaten propagiert, wann immer es geht mit nur einer Connection zu arbeiten, er scheint zu wissen warum.

Gruß
K-H

[Sybok Factor]

Versuche mal vor dem setzen auf DSN
AdoConnection.ConnectionString='';
Ist DSN als Widestring deklariert? Auch so eine mögliche Fehlerquelle.

Viele Grüße
Sybok Factor

[shmia]

Bei ADO Komponenten muss man folgende Regeln beachten!
1.) es darf nur eine einzige ADOConnection pro Datenbank geben
2.) alle ADOQuery, ADOTable, ADOCommand, ADODataset müssen auf diese Connection verweisen und dürfen keinen eigenen ConnectionString haben
3.) Property [ADOConnection].Connected muss zur Entwicklungszeit auf False sein
4.) ALLE Queries, Tables, ... müssen zur Entwicklungszeit inaktiv sein (Active=False)
5.) Sobald man im Objekt-Inspektor an einer Query herumspielt, wird die Query kurzzeitig aktiv.
Damit wird aber auch die ADOConnection aktiv.
Wenn man nicht aufpasst und einfach nur kompiliert kann Punkt 3.) verletzt werden.
Projekt schliesen, neu öffnen und Build-All kann dann helfen.

Zur Laufzeit ergibt sich dann folgendes Problem:
Irgend eine ADOQuery steht versehentlich auf Active=True.
Dies bewirkt automatisch, dass die ADOConnection verbunden wird.
Allerdings ist zu diesem Zeitpunkt der ConnectionString noch nicht gesetzt.
Damit wird ein falscher ConnectionString (nämlich der der auf die Entwickler DB zeigt) verwendet.
Deshalb sollte man die Punkte 1. bis 5. genau beachten.

[Sybok Factor]

@ shmia:
Im Großen und Ganzen hast du recht, aber ich habe durchaus Tabellen in TAdoDataSet zur Entwicklungszeit aktiv und kann trotzdem den ConnectionString zur Laufzeit umbauen.
Ich nehme an, dass die Nichtbeachtung deiner Regeln bei Anwendungen zu Problemen führt, die alle Fenster bereits beim Programmstart erzeugen?

Du hast mit deinem Hinweis recht, dass das Umbiegen des ConnectionStrings nur funktioniert, wenn die Connection nicht aktiv ist.

Viele Grüße
Sybok Factor