MyDac Erfahrung

[Edelfix]

Das Problem sind nach wie vor die großen Datenmengen. Die Table Komponente kommt damit nicht zu recht.
Mit "FetchAll" true dauert der Open Befehl viel zu lange und mit "FatechAll" false kommen die genannten Fehlermeldungen.

Jetzt kann der Hinweis das man mit SQL Arbeiten soll und LIMIT verwenden.

Jetzt habe ich aber festgestellt das der Befehl "Locate" nur in der im Client befindlichen Menge sucht.
Wenn ich "LIMIT 100" einstelle dann findet "Locate" nur etwas in den 100. Wenn der Datensatz gerade nicht dabei ist dann wird auch nichts gefunden.
Die Daten haben Lücken und unterschiedliche Nummernkreise. Sie sind nicht einfach fortlaufend.

Der Vorschlag von ChatGPT ist eine drei Stufen Lösung.
1. Mit einer separaten Query nach dem Datensatz suchen.
2. Weitere 100 holen mit dem "Offset" auf die gefundene ID damit im DBGrid nicht nur der gefundene Datensatz erscheint.
3. Jetzt mit "Locate" auf den gesuchten Datensatz im Grid positionieren.

Das kommt mir aber sehr umständlich vor. Das müsste auch anders gehen.

[Bernhard Geyer]

Zitat von Edelfix:

Das kommt mir aber sehr umständlich vor. Das müsste auch anders gehen.

Nö. Du kannst nicht alles haben.
Und wenn du eine DBMS nutzt, da z.B. keine Serverseitigen Curser hat (mit den Nachteilen, wenn man diese Nutzt), dann musst du halt "drumherum" arbeiten.

Aber auch wenn man diese hat. Wer schaut sich schon am Client Mio. Datensätze in einem Grid an.

Selbst haben wir ein 2stufige Logik um Grid mit "mehr als 5 Einträgen" hin zu bekommen
1, Hole alle Primärschlüssel
2, Beim Anzeigen im Grid hole Rest für diesen Datensatz

Zusätzlich gibt es ein Limit wie viele Primärschlüssel geholt werden dürfen/sollen.

[fred.ahrens]

Zitat von Edelfix:

Das Problem sind nach wie vor die großen Datenmengen. Die Table Komponente kommt damit nicht zu recht.
Mit "FetchAll" true dauert der Open Befehl viel zu lange und mit "FatechAll" false kommen die genannten Fehlermeldungen.
[...]
Das kommt mir aber sehr umständlich vor. Das müsste auch anders gehen.

Das Suchen musst du dem Server überlassen - genau dafür ist er da und optimiert. Sobald du anfängst große Datenmengen vom Server zu holen und dann erst auszuwerten, baust du dir solche Probleme ins Projekt ein.

Wir haben genau die selbe Situation hier gehabt und haben dann schweren Herzens auf Queries umgestellt, die nach Möglichkeit alle Auswertungen auf dem Server ausführen. Am Ende hat es sich aber gelohnt. Der Serverzugriff ist extrem beschleunigt und Probleme durch zu große Ergebnissätze gibt's auch nicht mehr.

[Frickler]

In MySQL gibt es noch so einen obskuren Zugriffsmodus namens "Handler". Der funktioniert wohl ähnlich wie beim guten alten dBase mit "Tabelle öffnen", "Index setzen", "nächsten Datensatz anfahren" usw. Soll angeblich deutlich schneller sein als per "Select". Man kann ihn in "MyTable" mit der Option "UseHandler" einschalten.
Siehe https://docs.devart.com/mydac/devart...usehandler.htm
Vielleicht bringt das ja was.

[Olli73]

Zum Glück hatte ich mich damals mit Firebird als Datenbank durchgesetzt. Wir haben nämlich, von der BDE kommend, sehr viele Table Komponenten im Einsatz. Mit Firebird kann man Server-Cursor mit Filter und Locate etc. nutzen. Zumindest mit FireDAC wird das dann alles am Server ausgeführt.

[Lemmy]

habe mydac mit Lazarus am Laufen unter Linux. Keine Problem, auch beim Verarbeiten großer (also wirklich großer) Datenmengen.

Zitat von Edelfix:

Jetzt habe ich aber festgestellt das der Befehl "Locate" nur in der im Client befindlichen Menge sucht.
Wenn ich "LIMIT 100" einstelle dann findet "Locate" nur etwas in den 100. Wenn der Datensatz gerade nicht dabei ist dann wird auch nichts gefunden.

scnr: Wer mit locate und DBMS arbeitet, hat eh jegliche Kontrolle verloren

Vergiss es einfach. vergiss irgendwelche Tablekomponenten.

nimm Querykomponenten, nimm spezialisierte SQL, die genau das tun, was du willst, und nur das.

Bitte verzeih, wenn ich das nicht explizit raus suche:
Ich habe mal eine BDE Anwendung auf Postgresql umgebaut und dabei pgDac verwendet. Und natürlich für die Umbauzeit TTable mit TpgTable ersetzt. Aber selbst für die Übergangszeit war das ne "sch****" selbst der Support hat mir damals geschrieben: TxTable Komponenten sind eigentlich nicht für einen wirklichen Einsatz gedacht.

[Medium]

Ich kann ähnliche Erfahrungen bei der Nutzung von *Table Komponenten berichten. Wir haben ein Produkt von Uralt (Paradox + BDE, ganz früher lief das sogar noch unter DOS (ja, TurboPascal) mit dBASE) auf MySQL umgestellt. Erst mit den Zeos-Komponenten. Als dann das Lizenzgeraffel mit MySQL anfing kamen wir zu MyDAC, und haben seit ein paar Jahren auch das DBMS auf MariaDB umgestellt.

Während all dieser Zeit haben wir immer noch hier und da *Table Komponenten mitgeschleppt, die immer wieder zu Problemen diversester Art geführt haben. Der gedankliche Schritt von der alten BDE-like Arbeitsweise hin zu vernünftigen SQL-Queries ist am Anfang ungewohnt, aber es lohnt sich!!

[Frickler]

Zitat von Lemmy:

scnr: Wer mit locate und DBMS arbeitet, hat eh jegliche Kontrolle verloren

Vergiss es einfach. vergiss irgendwelche Tablekomponenten.

Und dann ersetzt man

Delphi-Quellcode:

tbl.Tablename := 'Blubb';
tbl.Filter := 'artikelnr = 4711';
tbl.Filtered := true;
tbl.Open;
if tbl.FindFirst then begin
  repeat
    tbl.Edit;
    tbl.FieldByName('bla').AsBoolean := false;
    tbl.Post;
  until not tbl.FindNext;
end;
tbl.Close;

durch

Delphi-Quellcode:

qry.SQL.Text := 'SELECT * FROM Blubb WHERE artikelnr = 4711';
qry.Open;
while not qry.Eof do begin
  qry.Edit;
  qry.FieldByName('bla').AsBoolean := false;
  qry.Post;
  qry.Next;
end;
qry.Close;

...und hat "von Table auf Query umgestellt"

Wer Verschlüsselung nutzen will mit den DevArt-Komponenten, ist sogar gezwungen, das so zu machen...

[Bernhard Geyer]

Zitat von Frickler:

qry.SQL.Text := 'SELECT * FROM Blubb WHERE artikelnr = 4711';

Und jetzt auch noch parametrisierte perpared Abfragen und man wird schneller und sichererer ...

[Lemmy]

Zitat von Frickler:

...und hat "von Table auf Query umgestellt"

boah ernsthaft? Den Satz habe ich geschrieben, dass man das halt auch nicht mahcen soll, ihn dann aber wieder gelöscht vor dem Post

Zitat von Frickler:

Wer Verschlüsselung nutzen will mit den DevArt-Komponenten, ist sogar gezwungen, das so zu machen...

wie meinen?