MyDac Erfahrung

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

[Olli73]

Anstatt alle Stellen im Code anzupassen, erstellst du dir eine eigene Komponente TMyTable, abgeleitet von TfdQuery, die du dann überall verwendest. Die erweiterst / überschreibst du dann so, dass du von außen damit arbeitest wie mit einer F(fd)Table Komponente, aber intern eine Query für die benötigten Datensätze verwendet wird. Z.B. überschreibst du das Locate mit der Vorgehensweise wie du sie im letzten Beitrag beschrieben hast.

Oder, wenn möglich, steigst du auf Firebird um (siehe mein vorheriger Beitrag).

[MyRealName]

Falls Du DevExpress noch zusätzlich im Einsatz hast, dann gibt es dort den Servermode. Der sucht auf dem Server und holt sich immer nur durch clevere Queries was er im Grid gerade anzeigt, auch beim Scrollen

[Edelfix]

Die Idee von Olli73 klingt vielversprechend.

Danke.