DIMOWA® SQL Resource Creator

[haentschman]

...weil ihr so nett gefragt habt...

27.10.2016 - 19:37 Update

[haentschman]

01.01.2017 - Update
* siehe ersten Post

[haentschman]

11.02.2017 - Update
* siehe ersten Post

[haentschman]

Hallöle...

Ich bin ja schwer enttäuscht...
Ich wußte das die Datenbank das Stiefkind jedes Programmieres ist. Aber mit so wenig Reaktion hatte ich nicht gerechnet. Nur 2 Lizenen angefragt...Reaktion = 0.

Wie macht ihr das im allgemeinen so? Querbeet über den QT verteilt? Quoted Orgie im Statement? Ohne Parameter? Es geht auch einfacher und es kostet nix. ...außer über seinen Schatten zu spingen.

Kann ich noch ein paar Fragen beantworten? Was habt ihr an dem Prinzip nicht verstanden?

Jetzt aber mal los...

[hoika]

Hallo,
wir bauen unsere Queries je nach Anforderungen dynamisch zusammen.
Statische SQL-Anweisungen haben wir nicht ...

[haentschman]

Zitat:

wir bauen unsere Queries je nach Anforderungen dynamisch zusammen.

...das finde ich Hardcore. Wie testet man sowas? Ich meine nicht "select * from Universe" sondern komplexe Statements oder Scripte?

[juergen]

Hallo,

ich oute mich mal. Ich habe den Ansatz dieses Programms (noch) nicht verstanden.

Ich nutze z.B. simple externe Textfiles für SQL Statements, für jede Query ein Textfile. Dazu gibt es 2 Programme: Das erste ist das Parametrierungsprogramm wo man das DBMS auswählt, die DB, die Zugangsdaten und das SQL Statement erstellt. Das SQL kann direkt ausgeführt und getestet werden. Heraus kommt von diesem 1. Programm ein verschlüsseltes Textfile mit den genannten Daten.
Das 2. Programm ist das eigentliche Kundenprogramm. Das liest die entsprechenden Textfiles ein und führt die Statements aus.
Der große Vorteil dieser Version: Ich kann ohne Delphi das SQL Statement auf Zuruf direkt beim Kunden anpassen.

So wie ich es verstehe bindet dein Programm die SQL_Statements in die Resource-Datei ein.
Was hat das für einen Vorteil gegenüber meinem Ansatz mit den Textfiles?

Sorry, für mein sicherlich nicht vorhandenes Wissen...

[haentschman]

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.

[MaBuSE]

Zitat von haentschman:

Ich bin ja schwer enttäuscht...
Ich wußte das die Datenbank das Stiefkind jedes Programmieres ist. Aber mit so wenig Reaktion hatte ich nicht gerechnet. Nur 2 Lizenen angefragt...Reaktion = 0.

Ich hoffe die Situation hat sich etwas gebessert.

Und ich finde es toll, das Du die Idee aus meinem Tutorial aufgegriffen hast und sogar ein eigenständiges Produkt daraus geworden ist.

Viele Grüße
MabuSE

[haentschman]

Hallöle...

Zitat:

Ich hoffe die Situation hat sich etwas gebessert.

Danke für die Blumen... Meine Euphorie ist am Ende. Ich konnte eigentlich für das Konzept nur 2 dafür begeistern... Wir sind allein auf weiter Flur.

Wenn ich Lust habe, und es für mich einen Gewinn bringt, mach ich noch was dran. ...ansonsten ist es verlorene Zeit.

Schade...

Auf den nächsten Delphi Tagen kann ich ja noch einen Vortrag halten...so vor der Rente.