[ADO] MaxRecords bzw. CacheSize

[arnof]

Zitat:

Zitat von MrSpock (Beitrag 1254266)

Habe gestern noch einmal ein kleines Testprogramm geschrieben. Egal, was ich unter MaxRecords oder CacheSize einstelle, der Treiber lädt immer alle Datensätze. Dann habe ich versucht über ein ADODataSet mithilfe von LIMIT die Anzahl zu beschränken, aber das kommt über dn Umweg ADO -> ODBC -> KHK My SQL wohl nicht beim Server an. Er ignoriert auch das LIMIT.

Jetzt habe ich die Anzahl der Datensätze aus der Kundentabelle über die KundenId blockweise Eingelesen, damit werden natürlich nur noch die Datensätze aus dem Block (z.B. so:)

Zitat:

SELECT * FROM Kunden WHERE Kundennummer >= '0000000000' AND Kundennummer < '5000000000'

geladen. Mal schauen, ob das jetzt funktioniert. Auch die Einstellungen zum asynchronen Lesen scheinen ignoriert zu werden.

In dem Testprogramm habe ich noch das Zeitlimit von 30 auf 60 Sekunden gesetzt, möglicherweise kann auch das noch helfen. Wobei die Fehlermeldung nicht "Timeout" sondern "Out of Memory" ist.

Das ist alles etwas verwirrend. :stupid:

Der Maxrecord geht in der Regel. Wie sieht dein Connectionsstring aus? Hier gibt es je nach Treiber auch Einstellungen, die dieses Aufheben können.

[Bernhard Geyer]

Delphi ADO und ODBC auf MySQL? Gibts da nicht zwangsweise ein paar ODBC-Einstellungen die man setzen sollte damit es stabil geht?
Frag mich aber nicht welche das sind. Die Infos sind schon ein paar Jahre hehr und seit dem wir direkt mit MySQL (mit DevArt-Kompos) kommunizieren gibts eigentlich keine Probleme mehr.

[arnof]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1254268)

Delphi ADO und ODBC auf MySQL? Gibts da nicht zwangsweise ein paar ODBC-Einstellungen die man setzen sollte damit es stabil geht?
Frag mich aber nicht welche das sind. Die Infos sind schon ein paar Jahre hehr und seit dem wir direkt mit MySQL (mit DevArt-Kompos) kommunizieren gibts eigentlich keine Probleme mehr.

So ist es! KHK ClasicLine (Sage) habe ich schon lange nicht mehr gesehen, früher hatten die irgendein was nicht Standard als Datenbank, deshalb frage ich nach dem ConnectionString, da sieht man was Sache ist!

[MrSpock]

Die KHK New Classic Line arbeitet mit MySQL als echte Datenbank gegenüber der alten Dateien-Struktur. Die CL liefert einen ODBC Treiber mit, den ich als System DNS unter der 32 bit Administrator Verwaltung eingerichtet habe. Hier kann ich dann die Mandantennummer, das Passwort und das Finanzjahr einstellen. Außerdem die Lock-Methode für die Tabellen, die ich auch "periodisch entsperren" eingerichtet habe.

In Delphi wähle ich dann diesen ODBC Eintrag für die ADOConnection aus. Bei mir läuft es auf dem lokalen Rechner wie "die wilde Wutz", beim Kunden nach der Umstellung auf die aktuelle New Classic Line leider nicht mehr.

[arnof]

Mit den ODBC Treibern und MySQL ist das so eine Geschichte von Bugs ...

Es gehen hier nur bestimmte Versionen von Treibern, beim nächsten Update kann alles wieder nicht gehen, die sind sehr Buggy!

Ich benutze entweder

V3.51.27 oder den V5.1.6

die sind nicht aktuell, aber die funktionieren!

Hier musst Du halt den User heraus bekommen, der bei der Datenbank eingerichtet ist um darauf zuzugreifen.

[MrSpock]

Leider geht das nicht. Man soll auf die New Classic Line nur mit den mitgelieferten ODBC Treibern von extern zugreifen. Dann ist aber gewährleistet, dass die Tabellen konsistent bleiben, weil SAGE dann eben alle Einträge in den Tabellen entsprechend aktualisiert. Ein direkten Zugreifen auf die MySQL Datenbank wird nicht unterstützt.

[arnof]

Zitat:

Zitat von MrSpock (Beitrag 1254299)

Leider geht das nicht. Man soll auf die New Classic Line nur mit den mitgelieferten ODBC Treibern von extern zugreifen. Dann ist aber gewährleistet, dass die Tabellen konsistent bleiben, weil SAGE dann eben alle Einträge in den Tabellen entsprechend aktualisiert. Ein direkten Zugreifen auf die MySQL Datenbank wird nicht unterstützt.

Ah, das ist mir zwar schleierhaft, wie das mit dem Treiber zusammenhängen soll. Ist wohl ehr ein Beitrag aus der Märchenstunde. Entweder das überwacht die Datenbank (entsprechendes Design) oder die Applikation. Aber bestimmt nicht der ODBC Treiber :wink:

[MrSpock]

Mein Beitrag sollte nicht als Aprilscherz verstanden werden. :shock: Ich habe noch nie einen ODBC Treiber geschrieben, aber mein Verständnis ist, dass der Treiber in Richtung Applikation eine standartisierte Schnittstelle zur Verfügung stellt. Es ist aber nicht so, dass z.B. die SQL Statements als pass through einfach an die Datenbank im Hintergrund weitergegeben wird. So könnte es durchaus sein, dass ein Insert oder Update Statement an eine StoredProcedure weitergeleitet wird, die dann etwas "mehr" macht als nur das Hinzufügen oder Aktualisieren der einen Tabelle. Von daher spielen dann ggf. der ODBC Treiber und die Datenbank zusammen, um die Konsistenz zu erhalten. Ein direkter MySQL Zugriff auf die Tabellen im Hintergrund mit beliebigen SQL Statements könnte deshalb ein Problem sein. So wird es auch in der SAGE KHK Dokumentation erläutert.

Und gerade diese Umsetzung scheint jetzt hier zum Problem werden. So wird wohl die CacheSize nicht wirklich abgebildet. Selbst ein SQL Statement mit z.B. LIMIT 100 wird offensichtlich nicht einfach durchgeleitet sondern vom Treiber modifiziert.

[MrSpock]

Leider führt mein Testprogramm, bei dem ich unter anderem die Daten nur noch blockweise lese auf dem Zielnetztwerk beim Kunden immer noch zu dem "Out of Memory" Fehler.

Hat jemand noch eine andere Idee, was zu dem Fehler führen kann, und wie man diesen vermeiden kann?

Hat jemand Zugriff auf eine aktuelle SAGE KHK New Classic Line 2014 im Netz, dem ich dann mal ein kleines Testprogramm zuschicken könnte, welches nur zwei Tabellen über die Kette ADO -> ODBC -> KHK MySQL anzeigt? Ich würde gerne sehen, ob der Fehler auch in anderen Netztwerken auftritt.

[arnof]

Schau Dir mal im Taskmanager deine Exee beim Kunden an, wenn die richtig 2GB geht dann ist OutofM....

Er läd alle Datensätze, wieviele sind das denn 100.000 oder 1.000.000 (Select Count(*) from xxx)