Moin...
@Alle
Ich fasse mal zusammen:
1. Firebird... Gute Wahl
2. UniDAC... es haben alle Zugriffskomponenten ihre Eigenarten. Bei mir waren es die Updates, die unabhängig vom Delphi zur Verfügung stehen und der Preis.
3.
Query ist dein Sichwort... aus welcher Komponente ist egal (UniDAC etc.)
Was ich anders machen würde (für die Zukunft) 
:
Zitat:
Dann legst du in deinem Delphi-Projekt erstmal ein Datenmodul an.
*möööp* Für jede
Query eine Komponente auf dem Datenmodul + Connection + etc. Ich habe schon Datenmodule mit mehr als 100 Querys gesehen. Wer hat da noch den Überbick. Alle Querys auf dem Datenmodul werden automatisch erzeugt obwohl sie vieleicht einmal gebraucht werden.
Zitat:
Im
Query suchst du zuerst das Property
SQL auf und trägst dort z.B. ein: select * from Userdata...
Wenn du alles richtig gemacht hast, sollte ein Click auf das Property Active die Datensatzmenge aus der Datenbank ins
Query laden. Ein Doppelklick auf das
Query öffnet den Abfrage-Editor, wo du die Inhalte der Tabelle abrufen kannst.
*möööp* Das ist zwar einfach das
SQL einzutragen aber du
verteilst die SQL komplett auf den Quelltext z.B. auf die Komponenten.
*möööp* Niemals die Property
ACTIVE auf
TRUE im
OI setzen.
*möööp* Die Inhalte der Tabelle werden / sollten mit einem vernüftigen externen Editor angezeigt werden.
Zitat:
Beim Entwickeln stellst du das Property LoginPromt deiner TFdConnection erstmal auf False, damit du nicht bei jedem Testlauf die Anmeldedaten (Username und Passwort) für den Firebird-Server eingeben musst.
*möööp* Auch wenn es funtioniert...Die Anmeldedaten der
DB haben nichts im QT oder Komponente zu suchen. Eine externe Speicherung ist dein Freund (INI etc.)
Meine Tipps (meine Meinung ):
1: !!! keine
DB Komponenten
* Am Anfang ist das sicher einfacher. Mit steigenden Anforderungen kommst du da nicht mehr zurecht. (Joins und der Speicherung der Selben etc.) Du nimmst dir Gestaltungsmöglichkeiten weil es die Komponente nicht als
DB Version gibt. Wie schon gesagt ist ein
StringGrid, in deinem Falle, eine Alternative.
2: Vermeidung einer direkten
permanenten DB Verbindung mit Querys im Netzwerk
* Der Letzte der den Datensatz schreibt hat gewonnen. (in Milisekunden) Wenn die Putze über das Netzwerkkabel stolpert sind alle Transaktionen "geschrieben"
3: Kapselung des
DB Zugriffs in einem Interface oder einer abstrakten Klasse statt
DB Module
* Mein
DB Interface hat eine procedure z.B. FillList(MeineList: TBlubbList). Die Anwendung übergibt die Liste, das Interface füllt sie aus und die Anwendung arbeitet damit. Dabei ist es unerheblich wo die Daten herkommen...aus DB1, DB2, Omas Kleiderschrank...
Hier hat man die Trennung.
* Die Instanz des Interfaces / Klasse kann problemlos mehrfach nach Bedarf erzeugt werden. Mit einem automatisch generieren Datamodule geht das eher nicht.
* Alle
DB Interaktionen sowie die
SQL Statements und deren Parameter sind im Qelltext vorhanden.
* Ein Austausch der
DB Komponenten ist "einfach" möglich. Stelle dir mal vor, die
SQL Statements müßtest du auch in die neue Komponente übertragen.
Viel Spaß...
4: Arbeiten mit Datenobjekten
* Ein Objekt repräsentiert Daten die ggf. aus verschieden Tabellen stammen können. (Join) Die Daten werden mit einer
Query, die erzeugt wird, aus verschiedenen Tabellen geholt. Damit hat die
Query ihre Arbeit erledigt und kann freigegen werden. Später "dröselt" die Datenbankklasse das Objekt wieder auf und speichert die Daten in die entsprechenden Tabellen. (7)
* Das Objekt läßt sich gut debuggen.
(Inhaltsanzeige)
5: Ablage der Datenobjekte
*
http://docwiki.embarcadero.com/Libra...ns.TObjectList
6: Ablage der
SQL
* Je nach Projekt kann man auch die
SQL Statements in einer Ressource vorhalten.
http://www.delphipraxis.net/49505-sq...einbinden.html
* ! WERBUNG
: Der Ressource Creator hilft dir dabei.
http://www.delphipraxis.net/190316-d...creator-2.html
7: Normalisierung der Datenbank
* Die Normalisierung kann man auch auf die Spitze treiben.
Aber die Trennung von Master / Detaildaten ist wichtig. Wenn man die Normalisierung einsetzt, hat man keine Chance
DB Komponenten zu verwenden. (Joins)
https://de.wikipedia.org/wiki/Normal...ng_(Datenbank)
Wie du siehst, eine Datenbank ist nicht nur eine Datenbank. Man kann vieles falsch machen was man dann später wieder mühsam korrigieren muß.
Mach dir ein Testprogramm um die verschieden Varianten zu testen ohne im Produktivcode was zu ändern. Wenn du dich für eine Variante entschieden hast, dann kannst du dich auf dein Programm loslassen...
Manche Varianten sind mit mehr Schreibarbeit verbunden was sich später hinaus wieder rechnet...Übersicht, Testbarkeit, mehrere
DBMS usw.
Alle Entwickler haben so ihre Varianten...
Du mußt nur das für dich passende raussuchen.