Daten ohne DBGrid

[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.

[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

[Slipstream]

Der ursprüngliche Fragensteller hatte doch deutlich gesagt, dass er neu im Datenbankmetier ist: "Bis jetzt bin ich/wir immer ohne DBMS in unserer Firma ausgekommen - zumindest was Eigenentwicklungen angeht."

Wieso soll man so jemandem dann die allerkompliziertesten Möglichkeiten anbieten? Meinst du nicht, dass der sich davon erschlagen fühlen muss? Ich habs nur gut gemeint. Wenn man mir das vor 20 Jahren so hochkompliziert erklärt hätte, hätte ichs damals nicht begriffen, glaub ich. Aber gleich sagen: So macht man das nicht, da muss man noch dieses und alles das und sonstnochwas beachten. Er will doch nur eine multiuserfähige Urlaubsplanung basteln. Und während die Leute ihre Urlaube eintragen, wedelt meistens sowieso keine Putzfrau mit den Netzwerkkabeln rum, oder? Die kommt doch erst nach Feierabend oder vor Bürobeginn. Schliesslich hab ich unseren Teamkalender (Terminkalender) auch in ein paar Tagen fertiggestellt, und das ganz ohne diese ganzen Sicherheitsbedenken. Den meisten Aufwand hat die Rechnerei mit den Tagen benötigt, und die Darstellung im StringGrid. Wenn man aber Anfänger in Sachen Datenbank ist, dann muss man da schon ein bissel früher ansetzen.