Moin...
Zitat:
Was hat das für einen Vorteil gegenüber meinem Ansatz mit den Textfiles?
Im Prinzip machen wir es gleich.
Extern sind die
SQL testbar und können auch vom Datenbankentwickler ggf. geändert werden.
Das ist der
entscheidende Punkt die Statements
nicht im Quelltext zu lagern sondern im Versionskontrollsystem. Wie man dann die
SQL weiterverarbeitet kommt auf den Einsatzzweck an. Ich habe mich für die Ressource entschieden.
Zitat:
So wie ich es verstehe bindet dein Programm die SQL_Statements in die Resource-Datei ein.
Die
kompletten Statements für
alle Datenbanken sind in der Ressource enthalten. Über einen Einzeiler werden die
SQL Statements geladen und dann zur
Query zugordnet. Aus der Ressource wird nur das Statement für das entsprechende
DBMS geladen. In der Regel wird der Quelltext nicht geändert.
Zitat:
Heraus kommt von diesem 1. Programm ein verschlüsseltes Textfile mit den genannten Daten.
Ist ja quasi mit der Ressource "identisch", nur das das File nicht mit einkompiliert wird.
Zitat:
Das erste ist das Parametrierungsprogramm wo man das
DBMS auswählt
Hier haben wir die Unterschiede. Ich habe mich für die Speicherung des
DBMS in der INI entschieden. Im Programm werden die Einstellungen gelesen und ein Interface erzeugt. Das Interface kennt die Ressource und lädt das entsprechende
SQL.
Zitat:
Was hat das für einen Vorteil gegenüber meinem Ansatz
Über den Editor muß ich mich nicht darum kümmern wo das eigentliche Statement filetechnisch abgelegt wird. Dem Projekt werden die Ordner "vorgegeben" und z.b. mit "EINFÜGEN" wird das entsprechende
SQL mit dem NAMEN automatisch in dem Ordner erzeugt. Ich muß mich nicht mehr um das Dateisystem kümmern (wo speichere ich was). Wenn verschiedene
DBMS im Einsatz sind wird das Statement auf alle
DBMS kopiert (echte Datei). Beim "KOPIEREN" wird auch der Inhalt in die anderen
DBMS kopiert. (weniger Schreibarbeit
) Das
SQL trägt selbst den Status damit im Team gesehen werden kann ob das
SQL "fertig" ist bzw. überhaupt ein
SQL im entsprechenden
DBMS vorhanden ist. (zu jedem
SQL Namen existiert pro
DBMS ein
SQL) Hier kann man sich kontrollieren. Über den Editor hat man auch die Syntax besser im Blick.
Zitat:
das
SQL Statement auf Zuruf direkt beim Kunden anpassen.
...wie oft kommt sowas vor?
Fazit:
Du hast dich für Textfiles entschieden.
Andere bauen sich die Statements dynamisch zusammen.
Wir ging es darum die "select * from universe" im Datenmodul oder in Form1 Fraktion zu "bekehren"
bzw. eine andere Variante aufzuzeigen. In diese Kategorie fällst du leider nicht.
Die Idee kam bei meinem letzten Arbeitgeber. Da existierten mehrere Datenmodule pro
DBMS. Wenn man mal eine Änderung hatte, Feld in der Datenbank z.B., mußte man alle Statements in den Datenmodulen mitführen...und keines vergessen.
Der Kontrollaufwand war furchtbar. Da mußte was passieren.
Die
externe Speicherung und
die Ressource erschien uns ideal.