MyDac Erfahrung

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

[fisipjm]

Zitat von 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 ...

Das ist richtig und wichtig!
Also wenns wirklich nur so eine "Billo" Aufgabe ist würde ich das sogar komplett in einen Einzeiler Paken
Sparst dir dadurch das ganze Cursor-Geschubse in gänze.

Delphi-Quellcode:

qry.Execute('UPDATE Blubb SET bla=:bla WHERE artikelnr = :artikelnr',[false,4711]);
...

Solange die SQL Query eine Connection hat, brauchst du dich um nichts mehr kümmern. Außer du brauchst natürlich die SQL danach wieder um die Daten darzustellen, dann würde ich es wahrscheinlich so lösen.

Delphi-Quellcode:

qry.connection.Execute('UPDATE Blubb SET bla=:bla WHERE artikelnr = :artikelnr',[false,4711]);
qry.open('SELECT * FROM Blubb WHERE artikelnr = :artikelnr ',[4711]);

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

[Edelfix]

Unsere Tabellen Komponenten sind immer mit einem DBGrid verbunden. Das DBGrid liegt auf einer Form aber die Table Komponente auf einem DataModul. Auch wenn die Maske grad nichts anzeigt so ist die Table von überall erreichbar. Es wird von unterschiedlichen Stellen aus ein Locate gemacht dann der Datnsatz (fals gefunden) in ein Record geladen und dann verarbeitet oder im DBGrid angezeigt.
Bis jetzt war das eine Zeile mit Locate. Wir mussten uns nicht darum kümmern ob das Locate dafür da ist ein Datensatz zu holen oder im Grid zu positionieren. Und davon etwas 2.000 mal im Projekt.
Jetzt muss ich mit „LIMIT 100“ für das DBGrid arbeiten und dafür sorgen das der gesucht Datensatz bei den 100 dabei ist um dann im DBGrid darauf zu positionieren oder nur ein Datensatz um dann mit einem Record zu arbeiten.
Der SQL Befehl währe dann:
1. Ich brauche eine separate SQL Komponente um den Datensatz zu suchen.
2. Jetzt der SQL Aufruf mit LIMI 100 und OFFSET (gesuchter Datensatz).
3. Und noch mit Locate im DBGrid auf den Datensatz positionieren.
Das ist mehr als nur eine Zeile.