Turbo Delphi + Interbase-Komponenten

[globetrotter77]

Na toll, habe gerade versucht, FIBPlus zu installieren.
Da kommt dann die Meldung "Detected Compilers" (s. Anhang)
huch, jetzt ist meine Datei weg!
naja, jedenfalls kann ich kein Delphi, sondern nur MIDAS Support auswählen.
Was nun? Brauche ich das? Nein, dachte ich bisher ...

[globetrotter77]

Zitat von Hansa:

Keine Komponente liefert die DB mit und auch nicht den DB-Server

Hat ja auch keiner erwartet, aber leider sagt hier immer der eine hü und der andere hott ... da kommt das Pferdchen eben nicht zum Traben ...

Zitat:

Es wurde alles zum Thema gesagt. Nur die Tat fehlt.

Auch die Tat fehlt nicht.
Mit den in Delphi mitgelieferten Komponenten habe ich ja längst schon verschiedene Installationen durchgeführt, weiß also durchaus, dass ich die GDB bzw. wohl besser FDB mitgeben muss und dazu eine embedded fbclient.dll sowie noch ein paar kleine Dateien ... fertig und funktioniert auch auf nem bis auf Windows völlig nackten Computer
Und wozu brauche ich doch noch IBExpert???
Nur für die Schönheit?
Klar gefällt mir das mit ner ansprechenden Oberfläche auch besser, aber unter "benötigt" verstehe ich was anderes.

[globetrotter77]

Also gut, ich fasse mal zusammen:
Die Trial-Version ist vom 27.01.2009 und wird beschrieben als
"FIBPlus installation package for Delphi/C++ Builder 2009"
Die jüngste Doku ist vom 23.07.2006 und bezieht sich auf
"FIBPlus help for Delphi 2006"
Und dann gibt es noch vom 20.06.2007 bzw. vom 15.03.2006
den "FIBPlus Developer's Guide in printable format (PDF). Part 1+2"
mit dem geheimnisvollen Hinweis "(NEW)".
Da kann ja nichts Vernünftiges drinstehen, was zur aktuellen Version passt.

Schauen wir also mal nach, bevor ich mir die Festplatte zumülle.
Und was stelle ich fest?

Nur beispielsweise:
TpFIBQuery has no standard interface to data-aware controls and is unidirectional.
Das kann ich beim besten Willen nicht gebrauchen.
Eine Table-artige Komponente gibt es offenbar genausowenig wie IndexDefs.

Und dann gibt es noch massenweise einzeilige Beschreibungen ohne zusätzliche, überflüssige Erläuterungen, wozu die jeweilige Function oder Procedure vielleicht da sein könnte.
Warum auch? Das errät ein ordentlicher Programmierer ja schon im Schlaf.
Bei den Versionen, in denen alles in die Komponentenpalette integriert wird, scheint es ein paar nette Generatoren zu geben, aber natürlich nicht für die Explorer-Varianten.

Ich muss zugeben, dass ich das letzte Mal eine so miese Beschreibung vor ca. 20 Jahren bei irgendeinem Großrechner gesehen habe

Ich glaube, das tu ich mir lieber nicht an ... kann ja sein, dass man mit der integrierten Variante gut arbeiten kann, aber beim Turbo Explorer kann ich mir das nicht vorstellen.

[Chemiker]

Hallo Globetrotter,

eine Table – Komponente brauchst Du nicht.

Für die Erstellung der Datenbank benutzt Du IBExpert, dass schließt das Erstellen der Indexe mit ein.
Diese Datenbank wird abgespeichert.

Die Verbindung wird mit folgenden FIBplus-Komponenten hergestellt (Die Beschreibung PartI+2 hast Du dir ja schon Angesehen.):

TpFIBDatabase
TpFIBDataSet
TpFIBTransaction

und TDataSource was bei den Datenzugriffs-Komponenten von Delphi mitgeliefert wird.

Zuvor muss Du den Firebird-Server installieren und z.B. als Applikation starten.

Du arbeitest mit einem Datenbankserver und nicht mit einer Desktop-Datenbank.

Bis bald Chemiker

[globetrotter77]

@Chemiker:
zunächst mal danke für deine Info!

Aber:

Zitat von Chemiker:

eine Table – Komponente brauchst Du nicht.

Für meine Zwecke wäre die sogar perfekt geeignet ...

Zitat:

Für die Erstellung der Datenbank benutzt Du IBExpert, dass schließt das Erstellen der Indexe mit ein.
Diese Datenbank wird abgespeichert.

Ist klar, das geht genauso wie bei jedem anderen DB-Tool auch, habe ich prototype-mäßig auch schon längst gemacht, wenn auch nicht mit IBExpert, dessen Notwendigkeit ich nach wie vor nicht so ganz einsehe, wenn man mal von der schöneren Optik absieht.
Die Indizes benötige ich allerdings tatsächlich (im Programm verfügbar und auswählbar - geht aber offenbar nicht)

Zitat:

Die Verbindung wird mit folgenden FIBplus-Komponenten hergestellt (Die Beschreibung PartI+2 hast Du dir ja schon Angesehen.):

Du meinst die 1,5 bis fast 3 Jahre alten Teile? Ja, die habe ich gesehen und war entsetzt.
Die befassen sich mit so nem Schmonzes wie "How to work with array fields", wovor schon vor 25 Jahren gewarnt wurde, statt einigermaßen sinnvolle Beispiele zu geben.

Zitat:

TpFIBDatabase
TpFIBDataSet
TpFIBTransaction

und TDataSource was bei den Datenzugriffs-Komponenten von Delphi mitgeliefert wird.

Habe ich auch gesehen, hab mir die Properties, Methods und Events angesehen und leider den Eindruck bekommen, dass das noch nicht das Gelbe vom Ei ist.

Zitat:

Zuvor muss Du den Firebird-Server installieren und z.B. als Applikation starten.
Du arbeitest mit einem Datenbankserver und nicht mit einer Desktop-Datenbank.

Genau deshalb bin ich auch entsetzt! Ich arbeite seit über 20 Jahren mit solchen Teilen, aber so ein Durcheinander habe ich selten erlebt.

Da kannst du natürlich überhaupt nichts dafür, aber so ist es trotzdem ... Pech!

Dennoch vielen Dank für die Hilfe! Zumindest weiß ich jetzt, dass ich einiges durchaus richtig gesehen habe ...

[mkinzler]

Zitat:

Für meine Zwecke wäre die sogar perfekt geeignet ...

Nein, da Tables gewisse Nachteile besitzen ( alle Felder, alle Datensätze werden auf einmal geladen ...)

Zitat:

Die befassen sich mit so nem Schmonzes wie "How to work with array fields", wovor schon vor 25 Jahren gewarnt wurde, statt einigermaßen sinnvolle Beispiele zu geben.

Zitat:

Habe ich auch gesehen, hab mir die Properties, Methods und Events angesehen und leider den Eindruck bekommen, dass das noch nicht das Gelbe vom Ei ist.

Was gefällt dir den nicht/fehlt?

Zitat:

Genau deshalb bin ich auch entsetzt! Ich arbeite seit über 20 Jahren mit solchen Teilen, aber so ein Durcheinander habe ich selten erlebt.

Das ist aber bei allen DBMS. Zudem entfällt die Installation bei der Verwendung des embedded-Server-Clients.

Zitat:

Dennoch vielen Dank für die Hilfe! Zumindest weiß ich jetzt, dass ich einiges durchaus richtig gesehen habe ... Smile

Das glaube ich nun wiederum nicht

[IBExpert]

hier noch mal das archiv mit ein wenig mehr Inhalten
vom Beispiel zu meinem Artikel

Ist damals leider ein falscher Pfad gewesen der auf der
entwickler seite archiviert wurde, aber es war schon immer
vorteilhaft, bei der Delphipraxis dabei zu sein

[IBExpert]

Zitat von globetrotter77:

@IBExpert:
1) Um beim Beispiel zu bleiben: Ist es nicht so, dass zusätzlich zum
JvUIBDataBase1 := TJvUIBDataBase.Create(Self);
noch ein
JvUIBDataBase1.Parent := Self;
erfolgen muss?

2) Irgendwo gab es unterschiedliche Meinungen dazu, ob eine so erzeugte Komponente noch im OnClose oder OnDestroy-Event mit

JvUIBDataBase1.Free;

freigegeben werden muss oder nicht. Was ist nun richtig?
Wenn überhaupt, würde ich persönlich es im OnDestroy-Event unterbringen, weil Gegenstück zu OnCreate.
Sauber programmiert wäre es aber natürlich nur dann, wenn man sich nicht mehr drum kümmern muss.

Passiert das nun automatisch, weil die Komponente quasi an die Form übergeben wurde?
Oder muss man selber dran denken?

aus meiner sicht ist es nur dann sauber programmiert wenn du selbst eine Strategie entwickelst, das alle von dir explizit erzeugten Komponenten von dir zu gegebener zeit wieder zerstörst.
Ich nutze zum beispiel fast immer eine Query Komponenteninstanz pro operation insert/update/delete (oft auch für simple selects) pro tabelle und lasse die instanz auch fast immer so lange instanziiert, wie das programm läuft.

Alle späteren Aufrufe profitieren dann von der Geschwindigkeit der bereits "prepareten" Query, d.h. der Server muss pro Befehl nicht erneut den Plan ermitteln usw. Es werden dann eben nur noch die parameter ausgetauscht und mit dem existierenden handle auf dem Server verarbeitet. Kann je nach Einzellfall durchaus 100% mehr speed bringen.

Diese einmal instanziierten Queries merke ich mir in einer Tlist und hole die bei Bedarf wieder raus, statt eine neue Instanz zu erzeugen (was so nach und nach auch einiges mehr an Speicher verbraten würde). Ich für meinen Teil weiss dann, das ich eben in diesem Fall bei Bedarf eben durch die Tlist gehe und jede Instanz rausschmeisse wenn ich das will. Die instanzen werden auch erst dann erzeugt wenn die das erste Mal gebraucht werden, sonst hat man beim Programmstart wieder unnötig lange wartezeiten. Man kann das bei Bedarf auch in eigene threads auslagern usw.

Das mit der TList macht Delphi übrigens ähnlich, siehe property components eines owners, aber die components nehmen bei Bedarf eben auch 100000 Queryinstanzen auf wenn man nicht nachdenkt und man wundert sich warum das dann so lahm ist.

Die Automatismen über den Owner, der als solcher für das zerstören der Childs zuständig ist, sind ganz nett, aber manchmal überschätzt. Man müllt da unbewusst manchmal was voll. Ich mach lieber als owner bei nicht visuellen Komponenten nil oder application. Dann kann ich auch selbst die Zerstörungsreihenfolge bestimmen (es ist manchmal nicht so nett, zuerst die database komponente zu erschiessen und danach erst die datasets, das bringt immer wieder lustige AVs). Bei visuellen Komponente (wozu aber die database nie gehört) ist dann auch der owner das formular, es sei denn, das selbe formular mißbrauche ich mehrfach und schmeiss da nach und nach die Komponenten wieder raus und erzeuge die wieder neu (was viele möglichkeiten bietet). Dann nehme ich die selbsterzeugten komponenten zumindest auch wieder in eine eigene TList auf.

Der Parent ist nur für das Zeichnen wichtig, du kannst jederzeit den Parent eines sichtbaren Controls auch zur Laufzeit verändert, so kannst du einen button von einem panel auf ein anderes verschieben mit button1.parent:=panel1; button1.parent:=panel2; usw.

Der Parent (oder besser die control instanz) kann aber zur Laufzeit zerstört werden mit z.B. freeandnil(panel2). Dein Button hat dann als parent nil, der button ist zwar noch im Speicher, aber nicht sichtbar (sehr unpraktisch in diesem Fall).

[globetrotter77]

Zitat von IBExpert:

hier noch mal das archiv mit ein wenig mehr Inhalten

Danke!

[globetrotter77]

Zitat von IBExpert:

aus meiner sicht ist es nur dann sauber programmiert wenn du selbst eine Strategie entwickelst, das alle von dir explizit erzeugten Komponenten von dir zu gegebener zeit wieder zerstörst.

Das sehe ich genauso! War ein bisschen falsch formuliert von mir, "richtig sauber programmiert" meinte ich "aus Delphi-Sicht", d.h. nur, wenn man sicher sein kann, dass sich jemand um den Restmüll kümmert, ist es ok. Ansonsten nehme ich das auch lieber selber in die Hand, und am besten in der umgekehrten Reihenfolge der Entstehung, dann kann auch nicht viel passieren mit unangenehmen Abhängigkeiten.

Zitat:

Ich nutze zum beispiel fast immer eine Query Komponenteninstanz pro operation insert/update/delete (oft auch für simple selects) pro tabelle und lasse die instanz auch fast immer so lange instanziiert, wie das programm läuft.

Halte ich für das Geschickteste. Wozu auch immer wieder neu von vorne anfangen? Von wenigen Ausnahmen abgesehen, kaum sinnvoll.

Zitat:

Diese einmal instanziierten Queries merke ich mir in einer Tlist ...

keine schlechte Idee, ich habe das sonst meist mit dynamischen Arrays gemacht.

Zitat:

Die Automatismen über den Owner, der als solcher für das zerstören der Childs zuständig ist, sind ganz nett, aber manchmal überschätzt. Man müllt da unbewusst manchmal was voll. Ich mach lieber als owner bei nicht visuellen Komponenten nil oder application.

Macht Application nicht das Gleiche? Dachte schon!

Zitat:

Dann kann ich auch selbst die Zerstörungsreihenfolge bestimmen (es ist manchmal nicht so nett, zuerst die database komponente zu erschiessen und danach erst die datasets, das bringt immer wieder lustige AVs).

zur Reihenfolge s.o.

Zitat:

Der Parent ist nur für das Zeichnen wichtig, ...

so dachte ich es mir ...

Zitat:

Der Parent ... kann aber zur Laufzeit zerstört werden mit z.B. freeandnil(panel2). Dein Button hat dann als parent nil, der button ist zwar noch im Speicher, aber nicht sichtbar (sehr unpraktisch in diesem Fall).

Aber doch hoffentlich nicht ohne mein Zutun!


Vielen Dank für die ausführlichen Erläuterungen, das ist immer wieder sehr hilfreich, auch wenn ich es gar nicht so viel anders angefangen hätte! ...