TSQLConnection: Vermisse sowas wie "OnWillConnect" bei ADO

[jensw_2000]

Wie löst ihr das Problem mit "zur Laufzeit konfigurierten DBX Connections", wenn ihr beim Erzeugen des Projektes vergessen habt, das Connection-Objekt im Designer auf Connected:=false zu setzen...?
Problematisch wird das ja spätestens dann, wenn euer Programm die Entwicklungsumgebung verlässt und beim Kunden installiert wird. Dort sind Servernamen, Datenbankpfade... in der Regel anders und beim Programmstart in der fremden Umgebung gibt es dann eine nette Exception beim Instanzieren des DataModules.

Delphi-Quellcode:

  Application.Initialize;
  Try 
    Application.CreateForm(TDataModule, DataModule);  // <<<  GRRR
  Except
    On E:Exception do
      Showmessage('Grrr! Ich Brot habe mal wieder ein Build mit einer aktiven DBX Connection zum Kunden geschleppt... Ab ins Auto und .. noch einmal machen!');
  End;

Bei ADO greift vor dem Verbindungsversuch das Event "OnWillConnect" in dem man alle seine Sünden wieder gerade biegen kann, indem man den ConnectionString mit gültigen Werten überschreibt.

DBX hat von Hause aus nichts Vergleichbares.
Das OnBeforeConnect Event wird leider nicht aufgerufen, wenn die Connected-Property bei der Instanzierung der TSQLConnection Klasse bereits den Wert "True" hatte (weil zur Entwurfszeit gesetzt).
Irgendwie muss man da doch eine saubere Lösung hinbekommen können.

Die Alternativen
- DBXConnection.ini ausliefern oder
- auf den "Komfort" eines ConnectionObjektes während der Entwurfszeit verzichten und alles zur Laufzeit erstellen oder
- nie vergessen das ConnectionObjekt beim letzten Build vor der Auslieferung auf disconnected zu stellen
haben alle erhebliche Nachteile bzw. Unsicherheiten.



Schöne Grüße,
Jens

[Bernhard Geyer]

Haben das Problem nicht. Da wir sowas wie DB-Gebundene Controls verwenden und auch die DB-Schnittstelle mit Bridge-Pattern DBMS-Unabhängig gestaltet ist das kein Problem. Der User bekommt im Programm beim verbinden eh einen eigenen Login-Dialog indem er gleich die wichtigestn Sachen wie Servername und Databasename und Typ der DB sieht.

[hoika]

Hallo,

Zitat:

nie vergessen das ConnectionObjekt beim letzten Build vor der Auslieferung auf disconnected zu stellen haben alle erhebliche Nachteile bzw. Unsicherheiten.

Kann man so nicht stehen lassen.
Wozu gibt es Unit-Tests ?
Ein Test erzeugt das DataModule und checkt, ob die Connection aktiv ist oder nicht.

Ausserdem muss eine neue Version doch testweise installiert werden ?
Dann fällt die falsche / fehlende Ini doch eh auf.

Klar sollte sein, dass ein Programm-Version erst ausgeliefert wird,
wenn sie alle Unit-Tests besteht.


Heiko

[jensw_2000]

Auf meinem Entwicklungssystem gibt es ja eine entsprechende ini für die DBX Connection.
Das funktioniert natürlich immer, egal ob die TSQLConnection beim Buil aktiv war oder nicht.
Die DBXConnection.ini kann ich in einigen Fällen auch mit zu den Kunden ausliefern und an Hand der örtlichen Gegebenheiten konfigurieren. In einigen Fällen geht es aber auch nicht, weil die DB-Einstellungen dort anderweitig "zentral" konfiguriert werden müssen.
Genau da wird es problematisch. Wenn beim Build eine verbundene TSQLConnection übersehen wurde, habe ich programmatisch keine Chance die Connection individuell zu konfigurieren, bevor diese im Constructor des Datamodules instanziert wird. Das führt zwangsläufig zu einer unbebandelten (unbehandelbaren) Exception während der Applikations-Initialisierung. Dieser Fall tritt ja auch auf, wenn die DB Parameter stimmen (ini usw.) und der DB-Server einfach nicht erreichbar ist.
Es ist einfach nur unglücklich, dass es bei DBX kein Event gibt, das in jedem Fall vor der eigentlichen Aktivierung der Datenbankverbindung ausgelöst wird.

Bei ADO (dbGo) gibt es genau diese Möglichkeit im "OnWillConnect" Event.
Die TAdoConnection Instanz löst das Event aus, BEVOR die Datenbankverbindung "real" hergestellt wird. Das Event wird im Constructor der TAdoConnection ausgelöst und bietet daher immer die Möglichkeit, alle Designtime Einstellungen zur Laufzeit bedarfsgerecht zu konfigurieren (oder den DB Verbindungsversuch abzubrechen, weil beispielsweise die Config im Application > Inizialize Abschnitt noch garnicht geladen werden konnte).

@Bernhard
Ein abstrakter DB-Layer hat enorme Vorteile. Leider habe ich dafür noch kein Framework gefunden, das mir wirklich zusagt (funktionell oder preislich).
Was benutzt ihr?

MFG
Jens

[Bernhard Geyer]

Zitat von jensw_2000:

@Bernhard
Ein abstrakter DB-Layer hat enorme Vorteile. Leider habe ich dafür noch kein Framework gefunden, das mir wirklich zusagt (funktionell oder preislich).
Was benutzt ihr?

Self-made seit ca. Anfang des Jahretausends entwickelt

[jensw_2000]

Habe ich denn irgendwie eine Chance die Property "Connected" der TSQLConnection-Klasse zur Laufzeit generell auf "False" zu setzen, bevor mein Programm eine Instanz des Datamodules erzeugt?
RTTI und typeinfo wären da vermutlich gute Wörter zum googeln...aber nun finde mal was, wenn du nicht genau weist wonach du suchst ....
Ist das ein Holzweg? Hat jemand zufällig einen Link parat?