Daten ohne DBGrid

[Kathmai]

Hallo Community,

die Suche habe ich schon bemüht (irgendwie), nur wenn man leider nicht weiß nach was man genau suchen muss ist das schwierig.

Bis jetzt bin ich/wir immer ohne DBMS in unserer Firma ausgekommen - zumindest was Eigenentwicklungen angeht. Wir haben einen Urlaubsplaner der von mir in Excel geschrieben wurde im Einsatz (siehe Screenshot). Mehrbenutzerfähigkeit kann man natürlich vergessen dabei...

Ich habe mir in der letzten Zeit ausgiebig Lehrvideos und Tutorials angesehen und erste "Gehversuche" mit Firebird / FireDAC gemacht.

Wo ich nun hänge ist, ich brauche bei der Umsetzung kein DBGrid oder sonstiges. Die Daten die in der DB gespeichert sind (geht eigentlich nur um Mehrbenutzerfähigkeit) werden in einer eigenen Komponente (VCL) dargestellt. Ähnlich wie im Screenshot mit Kürzeln und paar weiteren Infos.

Wie kann ich nun die Daten aus einem Dataset (?) auslesen (sowie schreiben) und wie bekomme ich diese Infos geliefert - als records / strings ect ?

Oder anders gesagt wie würdet Ihr das Umsetzen was ich da vorhabe... Ist Firebird das richtige oder PostgresSQL über FireDAC oder lieber UniDAC?

Wäre für jede Hilfe dankbar.

Gruß
Kathmai

Edit: Es sollen ca. 4-6 Leute darauf zugreifen... Problem bei Excel war/ist, daß es die meisten nach der Bearbeitung Excel aufließen und irgendwann in unregelmäßigen Abständen nach dem Schließen / beenden eine Fehlermeldung gab mit ungefähr "Kann nicht bearbeitet werden .- durch Benutzer tt_customer geöffnet" obwohls keiner mehr auf hatte.

[hoika]

Hallo,
such dir ein Tutorial über Queries.

SQL:
Select * From
Insert Into

usw.

[juergen]

Hallo,

Zitat von Kathmai:

Oder anders gesagt wie würdet Ihr das Umsetzen was ich da vorhabe... Ist Firebird das richtige oder PostgresSQL über FireDAC oder lieber UniDAC?

Welche DB du nimmst ist *für diese Anforderung* egal.
Welche DB-Komponente du *für diese Anforderung* nimmst ist auch egal. FireDac ist um einiges teurer und ist immer an deine gekaufte Delphi-Version gebunden.
UNIDAC gibt es für jede Delphiversion, auch bei nachfolgenden Updates, ist also ein Vorteil. Wenn du nicht auf den Servermode von DevExpress angewiesen bist würde ich UNIDAC nehmen.
Oder hast du schon FireDAC? =>

Zitat von Kathmai:

erste "Gehversuche" mit Firebird / FireDAC gemacht...

Da du schon eine Komponente für die Visualisierung hast... Ist diese nicht datengebunden?

Eine Query kannst du in etwa so auslesen:

Code:

  Query1.First;
  while not(Query1.eof) do begin
    for i := 0 to Query1.FieldCount - 1 do begin
      // füllen deines Grids
    end;
    Query1.Next;
  end;

[Kathmai]

Zitat von juergen:

Oder hast du schon FireDAC?

Chef hat damals in weißer vorraussicht D10.1 Pro + FireDAC Addon bezahlt für Firma - wäre mir zu teuer. Pro selbst ist schon nicht gerade "preiswert".

Zitat von juergen:

Da du schon eine Komponente für die Visualisierung hast... Ist diese nicht datengebunden?

Jaein - bin grad am Entwickeln. Bin bei der Komponente noch am tüfteln zwecks Drucken (Canvas über Parameter - Print und Paint).

Hab schon mittlerweile durch den Tip von hoika mich mit den FDQuery beschäftigt und schon gefilterte Spalten in Memofelder "geschoben" damit. Hänge gerade bei den Parametern fest. Nur Verbindung über Teamviewer ist lahm da machts net wirklich Spaß zu arbeiten...

IBDac/UniDac würde mir persönlich besser gefallen weil nicht gebunden - und kosten tun sie verhältnismäßig auch net viel bei 290 bzw. 430€ netto.

Hab noch viel zu lernen / testen mit Datenbanken.

Aber der Tip mit Query's hat schon viel geholfen danke.

[Slipstream]

Zitat von Kathmai:

Hallo Community, die Suche habe ich schon bemüht (irgendwie), nur wenn man leider nicht weiß nach was man genau suchen muss ist das schwierig.

Einen Kalender mit Firebird und IbDac unter Delphi 2010 hab ich auch schonmal gebaut. War Teil einer umfangreichen Terminverwaltung für eine größere Firma. Für die Darstellung der Termine hab ich dennoch Grids verwendet, jedoch kein DBGrid, sondern StringGrids.

Am besten du fängst mit Konfiguration der Datenbank an. Dazu lädst du dir den Datenbankmanager von IbExpert herunter, der ist in der Personalversion kostenlos, das reicht in den meisten Fällen aus. Um die persönlichen Einstellungen der Benutzer ebenfalls in der Datenbank zu speichern, legst du eine Benutzertabelle an, die in ihren Spalten alle Optionen enthält, die der Benutzer abspeichern kann. Damit wäre erstmal gewährleistet, daß die Benutzereinstellungen auch beim Rechnerwechsel verfügbar bleiben.

Im Menü Datenbank des IBExpert Datenbankmanagers wählst du dein Eintrag Datenbank erzeugen. Befindet sich Firebird-Server und Datenbank auf deinem Arbeitsrechner, wählst du als Server local aus, ansonsten Remote und das entsprechende Protokoll. Beim lokalen Server musst du Servername und Port nicht angeben. Danach wählst du den Datenbanknamen. Der Eintrag Clientbibliothek sollte die fbclient.dll im Order Windows/System32 beinhalten. Die anderen Einträge sind selbsterklärend.

Benötigst du Boolean-Felder in deinem Projekt, must du dir erstmal eine Boolean-Definition anfertigen. Dazu doppelklickst du erstmal auf deine frisch angelegte Datenbank, worauf sich der Datenbank-Tree öffnet. Ganz oben wählst du mittels Rechtsklick Neue Domäne. Dort gibst du dann als Name z.B. MYBOOL an. Die Boolean-Deklaration verlangt einen Bezeichner, der die Zeichenfolge bool beinhaltet. Als Feldtyp wählst du SmallInt, weil Firedac das so erwartet, Unidac verlangt hier z.B. Integer. Das Feld Nicht Null wird angekreuzt. Standardquelle ist z.B. 0, das steht für False, oder 1, das wäre True. Im Feld Check steht VALUE IN (0,1), in die Feldbeschreibung kannst du reinschreiben, was du möchtst.

Dann klickst du mit rechts auf Tabellen und wählst Neue Tabelle. Dort trägst du zuerst den Tabellen-Namen ein, z.B. USERDATA. Dann legst du einen Primary Key an. Mit einem Doppelklick in das Feld PK wird diese Spalte deiner neuen Tabelle zum Hauptschlüssel. Als Feldname wählst du z.B. ID_USERDATA oder was auch immer. Um bei jedem neuen Datensatz automatisch den PrimaryKey hochzuzählen, machst du einen Doppelklick auf das Feld AI und erzeugst im erscheinenden Dialog einen Generator, einen Trigger und eine Prozedur.

Danach legst du weitere Userdaten-Spalten an, z.B. Username und Passwort für den Programmzugriff, Breite und Position des Programmfensters und alles sonst, was dein Herz begehrt. Hast du die Tabelle USERDATA fertig, klickst du auf den Blitz oben links und kompilierst deine Eingaben. Danach hast du eine Tabelle USERDATA, jedoch ohne Einträge. Die ersten Einträge machst du am besten auch mit dem IbExpert, indem du auf den Dateireiter Daten klickst, wo du dann Daten eingeben kannst.

Das wäre also der Schnelleinstieg in die Datenbankentwicklung.

Dann legst du in deinem Delphi-Projekt erstmal ein Datenmodul an. Dort hinein kommen dann alle Datenbank-Komponenten. In den Units, die dann Datenbank-Konnektivität benötigen, fügst du die Datenmodul-Unit in die Uses ein, das kann auch im Implementierungabschnitt geschehen.

Wenn du mit Firedac arbeitest, ist ein bisschen was zu beachten. Zuerst benötigst du eine TFdConnection, das ist die Datenbankverbindungskomponente. Danach benötigst du aber auch gleich mindestens eine TFDTransaction, besser zwei, weil du dann für normale Transaktionen und für Update-Transaktionen unterschiedliche Komponenten verwenden kannst. Des weiteren brauchst du einen TFDGUIxWaitCursor und einen TFDPhysFBDriverLink auf dem Datenmodul.

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. Nun gehst du zum Property Params Als Characterset stellst du das ein, was du beim Anlegen deiner Datenbank eingestellt hast. Ich würde hier von vorneherein zu UTF8 raten, was du damit alle verfügbaren Zeichen in Strings verwenden kannst. Unter Database gibst du den vollständigen Datenbank-Namen (=mit Pfadangaben) ein oder wählst ihn aus dem Dateidialog. Ganz wichtig, wenn du Boolean-Felder verwenden willst: Das Property ExtendedMetaData muss auf True stehen. Als SQL-Dialekt sollte 3 gewählt werden, in den Properties Password und Username sollten gültige Daten stehen. Ganz unten stehen dann noch die Properties Transaction und UpdateTransaction aus, wo du deine beiden Transaktionskomponenten einstellst.

Wenn du alles richtig gemacht hast, sollte ein Klick auf das Property Connected die Verbindung zur Datenbank herstellen.

Nun legst du ein TFDQuery auf das Datenmodul. Hast du nur eine Datenbank-Komponente auf dem Modul, wird diese beim Query automatisch eingetragen. Im Query suchst du zuerst das Property SQL auf und trägst dort z.B. ein: select * from Userdata. Das wäre deine Tabelle Userdata in der Datenbank. Unter Transaction und UpdateTransaction wählst du die beiden Transaktionskompenten, die sinnvollerweise entsprechende Bezeichner tragen, z.B. TransMain und TransUp. In den UpdateOptions trägst du nun unter AutoIncFields den Primary-Key ein, wenn du ihn in der Datenbank bereits als automatisch hochzählendes Feld angelegt hast. Unter Generatorname kommt der FB-Generator rein, und unter KeyFields wieder der Primary-Key. Unter UpdateTableName kommt der Tabellenname rein.

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.

So, das war jetzt eine Kurzanleitung zum Einstieg. Morgen bei Bedarf weiteres.

[jobo]

Zitat von Kathmai:

Hab schon mittlerweile durch den Tip von hoika mich mit den FDQuery beschäftigt und schon gefilterte Spalten in Memofelder "geschoben" damit. Hänge gerade bei den Parametern fest. Nur Verbindung über Teamviewer ist lahm da machts net wirklich Spaß zu arbeiten...

Wenn Du per Query bereits Daten holen kannst, dann kannst Du per Query auch Daten ändern oder einfügen.
Daten holen: Select ...
Daten ändern: Update ...
Daten einfügen: Insert ...
Löschen: Delete ...

[haentschman]

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.

[p80286]

Zitat von haentschman:

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.

Wer macht den sowas?

Um ein Stringgrid zu befüllen würde sich meiner Meinung nach eine Stringliste anbieten, das scheint mir am flexibelsten. Wenn die meisten Daten in ein record passen, bist Du mit einer Liste allerdings besser bedient.
das sieht dann im Prinzip so aus: (pseudocode)

Delphi-Quellcode:

var 
  datenliste : tstringlist;
  mysqltext : string;

begin
  datenliste:=TStringlist.Create;
  HoleDatenperQuery(mysqltext,datenliste);
  if datenliste.count>0 then
    FülleStringgrid(datenliste);
  Datenliste.free;
end;

Die TStringlist kannst Du natürlich durch jeden ListenTyp ersetzen, der Dir besser geeignet scheint.


Gruß
K-H

[Slipstream]

Zitat von haentschman:

Alle Entwickler haben so ihre Varianten... Du mußt nur das für dich passende raussuchen.

Das ist auf jeden Fall immer richtig, und es kommt auch darauf an, was das für eine Anwendung ist. Wir haben hier zum Bispiel langjährig gepflegte Grossprojekte für Multiuser im Netzwerk, da arbeiten wir selbstverständich auf Sicherheit: Die Rechner besitzen alle mindestens 16 Gigabyte Ram, ein Großteil der benötigten Daten wird über Objektlisten im Speicher vorgehalten, nicht mehr benötigte Daten werden zurückgeschrieben und die Objektlisten freigegeben.

Wir haben aber auch Kleinprojekte für kleinere Firmen oder für den Massenmarkt, da arbeiten wir anders, weil hier nich so viel Profit drin ist und wir deshalb schneller entwickeln müssen - das berühmte RAD. Meistens sind das auch lokale Anwendungen, die mit Embedded-FB ausgestattet sind. Da braucht man diese Sicherheitsvorkehrungen weger der Putzfrau nicht wirklich. Einige Projekte haben wir übernommen und müssten die neu aufbauen, wenn wir dort immer höchste Sicherheit haben wollten.

Mein Beitrag sollte nichts anderes sein als ein einfacher Einstieg ins Datenbankmilieu.
Weil sowas wies scheint nicht erwünscht ist, lass ichs in Zukunft natürlich gerne bleiben. Ich möcht hier keinen konkurrieren.

[p80286]

Zitat von Slipstream:

Mein Beitrag sollte nichts anderes sein als ein einfacher Einstieg ins Datenbankmilieu.
Weil sowas wies scheint nicht erwünscht ist, lass ichs in Zukunft natürlich gerne bleiben. Ich möcht hier keinen konkurrieren.

Nö warum? Das wäre ein Weg zum Ziel, und wahrscheinlich der, der das schnellste Erfolgserlebnis verspricht.
Nur z.B. active im OI auf true zu setzen, kann gewaltig in die Hose gehen, falls mal die Datenbank nicht verfügbar ist. Das muß man wissen! ansonsten sind wir hier nicht einer Meinung was Datenbanken und ihre Anbindung angeht, und das ist auch gut so, dann hat man immer die Möglichkeit seine eigene Herangehensweise zu überprüfen.

Gruß
K-H