MyDac Erfahrung

[Frickler]

Zitat:

Zitat von Lemmy (Beitrag 1547699)

Zitat:

Zitat von Frickler (Beitrag 1547688)

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

wie meinen?

Aus einer Frage im DevArt-Forum:

Zitat:

Please note that to encrypt data, you must pass values to the dataset fields.

To insert or modify an encrypted field, use the Append/Insert/Edit... Post methods and set the SQL expression to "SELECT..." (instead of "INSERT/UPDATE") for the TIBCQuery.SQL.Text property.

Da gehts zwar um IBDAC, aber was die Verschlüsslung angeht, verhalten sich bei DevArt alle *DACs gleich.
(siehe https://support.devart.com/portal/en...-tibcencryptor)

...aber wir schweifen ab!

@Edelfix: Was für eine Datenbank habt Ihr denn benutzt, bevor Ihr auf MariaDB gewechselt habt?

[Edelfix]

@Frickler. Wir nutzen die ADS (Advantage Database Server). Ist aber von SAP aufgekauft und eingestampft worden. Zum Glück läuft die DB noch.
Es kommt aber der Tag an dem ein Windows Update dafür sorgen wird das die DB einfach nicht mehr startet. Da müssen wir gegen wirken.

[Sinspin]

Oh ja, same same. So schön wie er ist, der ADS Server. Aber irgendwann geht er nicht mehr. Wir werden wohl auf Postgres wechseln.

[Frickler]

Ein Leidensgenosse!

Wir stellen aktuell alles um auf Firebird. Was etwa Reporting-SQL angeht, erreiche ich z.T. die sechsfache Geschwindigkeit wie bei ADS.

Wir hatten auch NexusDB ins Auge gefasst, weil das ein Server ist, der auch auf Tabellenkomponenten - ganz ohne SQL wenn man will - serverbasierte Cursor erlaubt. Zudem liegt er komplett im Quelltext vor, und man kann ihn mit Plugins erweitern. Dafür gibt es Defizite beim SQL, es geht z.B. kein MERGE oder sowas wie "UPDATE OR INSERT" bei Firebird. Und keine berechneten Indexe.
Wir machen aber relativ wenig mit purem ISAM, praktisch alle Datenbearbeitung, Grids und DBEDits, Reporting usw. basiert bei uns auf von der Datenbank entkoppelten ClientDataSets.

P.S.: Firebird ist vor allem auch einfach zu installieren. Wir bereiten eine sogenannte "ZIP-Installation" vor, die muss beim Kunden nur noch in einen Ordner entpackt werden. Dann noch den Service per CMD Datei installieren, und das wars schon.

[Sinspin]

Wir haben Postgres schon für eine Hardware Schnittstelle laufen. Zugriff via FD (FireDac) ist ganz einfach.
Da wir schon für ADS auf die FD Komponenten umgestiegen sind sollte / müsste ich auch dann keine größere Probleme haben.
Das witzige ist, ADS läuft mit den FD Komponenten schneller als mit den ADS eigenen.

[Olli73]

Zitat:

Zitat von Frickler (Beitrag 1547806)

Ein Leidensgenosse!

Wir stellen aktuell alles um auf Firebird.
...
Wir hatten auch NexusDB ins Auge gefasst, weil das ein Server ist, der auch auf Tabellenkomponenten - ganz ohne SQL wenn man will - serverbasierte Cursor erlaubt.

Kann Firebird doch auch...

[Frickler]

Zitat:

Zitat von Olli73 (Beitrag 1547822)

Zitat:

Zitat von Frickler (Beitrag 1547806)

Wir hatten auch NexusDB ins Auge gefasst, weil das ein Server ist, der auch auf Tabellenkomponenten - ganz ohne SQL wenn man will - serverbasierte Cursor erlaubt.

Kann Firebird doch auch...

ISAM (also Tabelle, nicht Query, mit Filter, Range und Co) mit serverbasiertem Cursor kann Firebird nicht. Die Zugriffskomponenten wie IBDAC, FireDAC etc können das mit allerlei SQL simulieren, aber nativ geht es nicht.

[Edelfix]

Ein Update für alle die auch mit MariaDB und MyDac Probleme haben.

Konnte alle aktuellen Probleme auf einen schlag lösen.
Wenn man möchte das MyDac so mit MariaDB arbeitet wie die ADS Komponenten mit der ADS Datenbank dann nimmt man am besten FireDac Komponenten.

Wir sind auf FireDac gewechselt und haben als erstes festgestellt das FireDac Komponenten in Delphi 10.4 zu alt sind und die entsprechende Fehlermeldung hat uns auch darauf hingewiesen.

Jetzt sind wir auf Delphi 12.3 gewechselt und die FireDac Komponenten arbeiten wunderbar. Wir können die ADS Komponenten eins zu eins austauschen.

[Codehunter]

Zitat:

Zitat von fred.ahrens (Beitrag 1547659)

Zitat:

Zitat von Edelfix (Beitrag 1547656)

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.

Genau so ist es richtig. Die Eingangsfrage beschreibt ja eine Lost Connection. Sowas hatte ich auch mal. Da sind zwei Faktoren zusammen gekommen: Die Konstruktion des Clients führte zu übergroßen Datenabfragen und der Mysql-Server war mit zu kleinen Caches konfiguriert. Denn bevor sie über TCP/IP auf die Reise geschickt werden, müssen die Daten vorher erstmal auf dem Server zusammengestellt werden. Dabei lief ihm ein Puffer über und der Server hat der TCP-Verbindung einfach die Türe zugeschlagen.

Suchen sollte man niemals clientseitig. Das funktioniert eine Weile, wenn man an der Umgebung nichts ändert. Aber dann kommen vllt. neue Arbeitsplätze dazu, die Serverlast steigt und schon sind die alten Probleme wieder da. In den vorherigen Posts wurde schon beschrieben, wie man mit WHERE-Klauseln und Queries arbeitet. Nachdem ich das Prinzip erstmal verstanden hatte, arbeite ich inzwischen ausschließlich mit Queries und gar nicht mehr mit Table-Komponenten. Locate geht auch auf Query-Objekten, manchmal macht das Sinn um in Schleifen kein Datenbank-Pingpong zu bauen. Aber immer nur auf eingegrenzten Datenmengen, nie über eine ganze physische Tabelle.