IBConnection.Connected=false setzen beim kompilieren

[Joh]

Moin,
mich kackt es gerade immer mal wieder an, wenn ich ein Programm beim Kunden einspiele:
dann bricht es ab mit Datenbank f:\... nicht gefunden.
Klar, die Datenbank liegt ja auch anderswo, steht ja auch brav in der ini.
Aber nach dem Testen wieder vergessen, Connection.Connected auf false zu setzen.

Bleibt mir wirklich nur, jedes Formular manuell zu checken?
OK, ich könnte auch in den lfm-Dateien nach Connected = True suchen.

Aber gibt es da nicht was eleganteres? Wie macht ihr das denn?

PS: wo ich gerade dabei bin: wozu dienen die Felddefinitionen in der TSQLQuery? Außer: das, wenn man die Abfrage ändert, es mal wieder beim Update im Gebälk kracht, weil ich vergessen habe, diese (unnützen) Felder zu aktualisieren.

[Sieben]

Mach dir eine eigene TIBConnection:

Code: Alles auswählen

  TJohIBConnection = class(TIBConnection)
  published
    property Connected stored False;
  end;

Nach demselben Muster, nur mit Active, auch TSQLTransaction und TSQLQuery. Zumindest die Transaction kann dir sonst die Connection implizit öffnen, bei der Query bin ich mir grad nicht sicher. Die Felddefinitionen dienen in erster Linie dazu, Properties und Events zur Designzeit zu setzen.

[charlytango]

Aber gibt es da nicht was eleganteres? Wie macht ihr das denn?

Ich mache das so

Im Laufe der Jahre hat sich für mich herausgestellt dass die Aktivierung einer Datenbankverbindung zur Designzeit (also Daten in der GUI ansehen) mehr Probleme macht als es löst. Deswegen mache ich das konsequent nicht mehr.

Mag sein dass sich die Lösungen verbessert haben doch da ich dahingehend nicht mehr auf dem Laufenden bin ist für mich kein Thema mehr.

Die Datenbankverbindung in meinen Programmen wird in einer Unit bzw einem Verbindungsobjekt gemanaged. Das kümmert sich um die richtigen Zugriffsbibliotheken, dei Datenbankverbindung, ggfs auch das Switchen zwischen Verbindungen, Einstellungen in INI-Files, Transaktion, SQL-Monitoring, Fehlerbehandlung, ordentliche Fehlermeldungen etc. etc.

Bei größeren Projekten ist das die Elternklasse die vererbt wird und dann kommen noch spezielle SQL-Befehle und Selects/Executes dazu (und noch ein paar ander Goodies) die sauber abgesichert im ganzen Programm zur Verfügung stehen.

Im oben genannten Link findest du ein Subset meiner Funktionen besonders angepasst auf Demo-Applikationen, doch im wesentlichen ist die Klasse allgemein einsetzbar und erstellt auch bei Bedarf die DB.

Auf den Formularen befinden sich nur TSQLQueries und TDataSource (bzw die ZEOS-Äquivalente) samt den datenaktiven Controls. Queries sind in der GUI immer geschlossen, denn sie haben in der GUI ja auch keine Funktion. Bei Formularen mit vielen TSQLQueries kommt schon mal ein Datenmodul zum Einsatz um die etwas übersichtlicher zu verwalten. Das ist dann aber auch ein Zeichen über andere Organisationsformen nachzudenken (zB Forms oder Subformulare)

Erst beim Erstellen der Formulare (und die erstelle ich außer dem Hauptformular alle zur gegebenen Zeit selbst) wird die DB-Verbindung aus dem Verbindungsobjekt im Code zugewiesen und die Query geöffnet.

[Joh]

Mach dir eine eigene TIBConnection:

Code: Alles auswählen

  TJohIBConnection = class(TIBConnection)
  published
    property Connected stored False;
  end;

Kann ich die eigenen Objekte auch in der Entwicklungsumgebung bearbeiten?
Oder geht das dann nur per Code?

[Joh]

Ich mache das so

klingt interessant.
Ist aber nichts, um ein bestehendes Projekt umzumodeln.

Ich hatte den Thread schon verfolgt, aber für mich auf die "kanst du dir irgendwann angucken"-Liste gesetzt.

Aktuell nutze ich eine Batch-Datei zum kompilieren:

Code: Alles auswählen

SET such='Connected = True'
SET ersetz='Connected = False'
FOR %%d in (*.lfm) do f:\Tools\sed\sed.exe -i "s/%such%/%ersetz%/g" %%d
f:\lazarus\lazbuild -B ifd.lpi
DEL sed*

Doof ist dabei nur, das ich im Eifer des Gefechts vergesse, die Batch aufzurufen und einfach mit F9 kompiliere...

[Sieben]

Kann ich die eigenen Objekte auch in der Entwicklungsumgebung bearbeiten?

Du musst sie eh installieren, da die 'stored'-Direktive ja von der Entwicklungsumgebung umgesetzt werden muss.

[Joh]

und das geht wie?

[charlytango]

klingt interessant.
Ist aber nichts, um ein bestehendes Projekt umzumodeln.

Ansichtssache ... und kommt aufs Projekt an. Von wie vielen Formularen reden wir denn?

Aktuell nutze ich eine Batch-Datei zum kompilieren:

Code: Alles auswählen

SET such='Connected = True'
SET ersetz='Connected = False'
FOR %%d in (*.lfm) do f:\Tools\sed\sed.exe -i "s/%such%/%ersetz%/g" %%d
f:\lazarus\lazbuild -B ifd.lpi
DEL sed*

Doof ist dabei nur, das ich im Eifer des Gefechts vergesse, die Batch aufzurufen und einfach mit F9 kompiliere...

Da lerne ich auch immer wieder was dazu. Interessanter Klimmzug, aber nachvollziehbar.
Dann bau dir doch die Batch-Datei in die GUI ein.

Tools - Configure External Tools

dann kannst du die Batchdatei auch aus der GUI starten

[Sieben]

und das geht wie?

Am bequemsten über Package / Neue Komponente. Bei der ersten wählst du 'Neues Package', die folgenden packst du dann in eben dieses neue Package 'JohDB' oder wie auch immer. Die IDE erstellt dir dann die Rümpfe für die jeweiligen neuen Komponenten sowie die Registrierung. Ich empfehle ein eigenes Unterverzeichnis für jedes eigene Package unter 'MyPackages' oder so. Nachdem du alle erstellt und die jeweiligen Zeilen eingetragen hast, das Package installieren. Du findest aber sicher noch Ausführlicheres in den Wikis oder der Hilfe...

Wenn du dich für das Einbinden der Batch-Datei entscheidest, würde ich aber auf jeden Fall und wie gesagt noch TSQLTransaction und TSQLQuery mit Active = False hinzufügen.

[Joh]

ich werde jetzt erstmal mit der Batch weitermachen und mir, wenn sich Zeit findet (heißt IMHO St. Nimmerleinstag, aber die Hoffnung stirbt bekanntermaßen zuletzt), Charlytangos Lösung angucken...

[Epcop]

Wegen der Batch Datei.

Projekte - Projekteinstellungen - Compilereinstellungen - Compiler-Kommandos:
"Vorher ausführen" -> Batch Datei eintragen
"Nachher ausführen" -> Batch Datei eintragen
Dann solltest du den normalen Komfort wieder haben.


Eine andere Idee, aber eher hässlich, zu Beginn prüfen, auf welchen Rechner (z.B. deinen Computername, oder eine Textdatei, die nur auf den Entwicklerrechner ist o.ä.) das Programm ausgeführt wird und dann dementsprechend automatisch die Connected setzen. Oder zwei unterschiedliche ini berücksichtigen, deine wenn vorhanden, ansonsten die Kunden ini. Ist

[Joh]

Wegen der Batch Datei.

Projekte - Projekteinstellungen - Compilereinstellungen - Compiler-Kommandos:
"Vorher ausführen" -> Batch Datei eintragen
"Nachher ausführen" -> Batch Datei eintragen
Dann solltest du den normalen Komfort wieder haben.

Hat leider den Nachteil, das ich immer wieder die Meldung bekomme, das sich Daten auf der Platte geändert haben
=> und die schienen nicht immer sauber übernommen zu werden

Eine andere Idee, aber eher hässlich, zu Beginn prüfen, auf welchen Rechner (z.B. deinen Computername, oder eine Textdatei, die nur auf den Entwicklerrechner ist o.ä.) das Programm ausgeführt wird und dann dementsprechend automatisch die Connected setzen. Oder zwei unterschiedliche ini berücksichtigen, deine wenn vorhanden, ansonsten die Kunden ini. Ist

zwei ini's habe ich ja. Aber das Problem ist ja gerade, das der Automatismus mit dem Connecten der Datenbank startet, bevor ich überhaupt auf die ini zugreifen kann. Also vor FormCreate.