Adoconnection liest keinen String

[shmia]

Zitat von Sybok Factor:

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

Das ist soweit richtig.
Nur ist es bei vorallem bei grossen Projekten so, dass man die Reihenfolge in der Datenmodule und Formulare erzeugt werden nicht 100% im Griff hat.
Lange Zeit läuft alles gut, aber vielleicht benötigt ein Formular dass frühzeitig erzeugt wird, ein weiteres Datenmodul.
Auf diesem Datenmodul sitzt dann vielleicht dummerweise ein aktives ADODataset und schon hat man ein Problem.

Noch gemeiner ist folgende Konstellation:
In der IDE ist das Datenmodul auf dem die ADOConnection liegt geöffnet. (Connected=False)
Jetzt braucht man nur versehentlich das Formular/Datenmodul mit dem aktiven ADODataset öffnen
um etwas nachzuschauen und die Connection wird automatisch aktiv. *)
Wenn man jetzt nicht aufpasst und in der IDE "Alles speichern" wählt wird die ADOConnection mit Connected=True abgespeichert.
Aber man bemerkt das Problem nicht; erst auf dem Zielrechner beim Endbenutzer gibt es Ärger.

*) die IDE müsste eine "Schatten"-ADOConnection, also eine Kopie der orginalen Connection benützen, dann wäre das Problem vom Tisch.

[Privateer3000]

Vielen Dank für Eure Antworten.

Diese " 5 Gebote" sind mir eigentlich bekannt.
Habe aber trotzdem keine aktive Komponente gefunden.
Interessant ist aber noch folgendes
im OnClose Ereignis der Anwendung schreibe ich die
DSN in die Registry, übernommen aus dem connectionstring der Ado.
Diese ist aber die korrekte.
Es ist aben nur beim Anwendungsstart, dass die "alte" versucht wird aufzubauen.
Ist aber der String leer kommt der Authentifizierungsfehler.
Es ist echt zum Mäuse melken...

[shmia]

Hast du schon einmal mit UDL-Dateien gearbeitet?
In einer UDL-Datei wird der gesamte ConnectionString gespeichert und kann vom Benutzer leicht (per Doppelklick!) geändert werden.
Dein Programm braucht sich darum überhaupt nicht zu kümmern.
Im Anhang ist eine UDL-Datei zum Testen.

Hier ein Beispiel wie du die Connection herstellen kannst:

Delphi-Quellcode:

  if ADOConnection1.Connected then
    // Prüfung, ob ADOConnection schon aktiv ist
    ShowMessage('Warnung: ADOConnection ist schon aktiv !');
  // ConnectionString aus UDL-Datei zuweisen
  // UDL-Datei heisst genau gleich wie deine EXE; hat aber nur die Endung .udl
  ADOConnectionSetupUDL(ADOConnection1, ''); 
  ADOConnection1.Connected := True;

Und hier noch die Hilfsfunktionen:

Delphi-Quellcode:

uses ...,ADODB;


resourcestring
  SUDLMissing = 'UDL-Datei "%s" nicht vorhanden !';

// liefert Dateiname inkl. Pfad der Anwendung oder der DLL
function GetModuleName: string;
var
   hi : HINST;
begin
   SetLength(Result, MAX_PATH);
   if IsLibrary then
      hi := HInstance
   else
      hi := 0;
   SetLength(Result, GetModuleFileName(hi, PChar(Result), length(Result)));
end;


procedure ADOConnectionSetupUDL(cn: TADOConnection; const UdlFile: string);
var
   FileName: string;
begin
   cn.Connected := False;

   FileName := UdlFile;

   if FileName='' then
      FileName := ChangeFileExt(GetModuleName, '.udl')
   else if ExtractFilePath(FileName) = '' then
      // Wenn kein Pfad übergeben wurde => Pfad der Exe eintragen
      FileName := ExtractFilePath(GetModuleName) + FileName;

   if not FileExists(FileName) then
      raise EADOError.CreateFmt('ADOConnectionSetupUDL(%s,%s) '#13#10+
         SUDLMissing, [cn.Name,UdlFile, filename]);

   cn.ConnectionString := 'FILE NAME=' + FileName; 
end;

[Bummi]

@shmia
Die immer wieder auftretende Problematik mit geöffneten Datasets zu Entwicklungszeit lassen sich durch eine Flagüberprüfung in BeforeConnect in den Griff bekommen, wenn das Flag nicht gesetzt (gesetzt wir nach dem Lesen des ConnectionsStrings aus der INI/Registry/Konfiguration) ist wird ein Abort abgesetzt.

[Privateer3000]

Das seltsame daran ist doch eigentlich
dass ich die prinzipielle Vorgehensweise schon
mehrmals eingesetzt habe.
Nur diesmal geht irgendwas schief...
Vllt. wäre es besser wenn mal jemand einen Blick darauf werfen
könnte.
Kann ja sein dass ich irgendwas übersehen habe.

Grüße

[Sir Rufo]

Zitat von Bummi:

@shmia
Die immer wieder auftretende Problematik mit geöffneten Datasets zu Entwicklungszeit lassen sich durch eine Flagüberprüfung in BeforeConnect in den Griff bekommen, wenn das Flag nicht gesetzt (gesetzt wir nach dem Lesen des ConnectionsStrings aus der INI/Registry/Konfiguration) ist wird ein Abort abgesetzt.

Das mit dem BeforeConnect ist eine gute Stelle ... aber warum ein Abort?
Ich setze in dem Event einfach den gewünschten ConnectionString

[Bummi]

@Sir Rufo

Machen wir in vielen Anwendungen auch so, es gibt aber einige bei denen durch die Erstellungsfolge ein anderes Vorgehen erwünscht ist, daher haben die Templates/Frameworks an diesen Stellen o.g. Code drin, der dann gegf. ersetzt wird, quasi als Sicherung.

[Privateer3000]

[QUOTE=shmia;1157838]Hast du schon einmal mit UDL-Dateien gearbeitet?
In einer UDL-Datei wird der gesamte ConnectionString gespeichert und kann vom Benutzer leicht (per Doppelklick!) geändert werden.
Dein Programm braucht sich darum überhaupt nicht zu kümmern.
Im Anhang ist eine UDL-Datei zum Testen.

Vielen Dank für Deine Anregung,
ich habe alle Schritte nochmal verfolgt.
Das setzen des Strings verläuft ohne Problem
erst beim ersten query knallts.
Jetzt habe ich keine Idee mehr, es ist wie verhext.
....

[Furtbichler]

Zitat von shmia:

Bei ADO Komponenten muss man folgende Regeln beachten!
1.) es darf nur eine einzige ADOConnection pro Datenbank geben
...

Das ist bei nie ein Problem gewesen. Aber deine weiteren Ausführungen sind entscheidend!
Ich erschlage sie mit GExperts: Dort kann man einstellen, das Delphi vor dem Compilieren dafür sorgt, das alle Connections und Datasets geschlossen sind (Set Component Properties).

Warum man nur eine Connection haben sollte, würde mich mal interessieren.

Zum Problem: Abfragen auf true/false = unnötig und gefährlich. (mehr unnötig als gefährlich)
Das löst aber nicht das Problem, sieht aber hübscher aus.

Delphi-Quellcode:

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

Der folgende Code aus Post #1 soll dein 'SetMinervaDSN' sein? So ist es moderner:

Delphi-Quellcode:

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

Ich hatte solange die gleichen Probleme wie Du, bis ich die 5 Regeln (na ja, 2-5) strikt durch Verwendung der GExperts eingehalten habe.

Bin ich auf einem fremden Delphi ohne GExperts, knallt mir das jedesmal um die Ohren.

Zitat von Privateer3000:

Das seltsame daran ist doch eigentlich dass ich die prinzipielle Vorgehensweise schon
mehrmals eingesetzt habe. Nur diesmal geht irgendwas schief...

Das klingt genauso wie wenn meine Programmierer vor der rauchenden Maschine stehen und sagen: "Ich hab eigentlich nix gemacht!"

Das Schöne an unserem Beruf ist doch: So eine SW ist deterministisch. Wenn's gestern lief und heute nicht, ist nicht das Wetter oder die Stimmung Schuld, sondern das gottverdammte System.

Du wirst zur Designzeit irgendwo rumgeklickelt haben, oder Delphi von mir aus von ganz alleine oder ein Kobold.

Sorge stringent dafür, das beim Start des Programms alle Verbindungen und Datasets tot sind (Lade GExperts oder verwende Bummis Trick, wobei der 'nur' meckert, was aber auch ok ist)

Noch ein Trick (auch bei Datasnap oder TCP): Suche per Explorer (Totalcommander, egal) in den (Text-)DFM-Dateien nach "Connected=True" oder "Active=True" usw. Wenn ich eine Stelle gefunden habe, war ich mir jedesmal sicher, das ich das unter Delphi geprüft hatte.

Merke: Je komplexer die IDE, desto mehr unsichtbare Kobolde frickeln an deinem Code rum

[Bummi]

Manchmal stellt man sich auch selbst ein Bein, wenn Du einen ConnectionString in folgender Art aufbaust

Code:

Provider=SQLOLEDB.1;Persist Security Info=False;User ID=sa;Initial Catalog=test;Data Source=BUMMI-MOBI

und LoginPrompt auf false setzt bekommt man den beschrieben Fehler auch, in dem Fall das Speichern des Kennwortes zulassen oder LoginPromt auf True setzen oder den String über ein eigenes Loginfenster ergänzen lassen.