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