[ADO] MaxRecords bzw. CacheSize

[MrSpock]

Hallo,

ich greife über ADO (ADOTable) und ODBC auf die KHK New CL zu.

Was ist der Unterschied der Eigenschaften MaxRecords und CacheSize?

[sx2008]

MaxRecords ist ein hartes Limit; d.h. auch wenn die Abfrage mehr Datensätze liefern könnte werden nur MaxRecords angezeigt.
Das ist z.B. nützlich wenn man grosse oder unbekannte Tabellen öffnet die potentiell Millionen Datensätze haben können.
Setzt man MaxRecords auf 500 ist sichergestellt dass die Anwendung nicht auf unbekannte Zeit blockiert weil zu viele Daten geschaufelt werden.

CacheSize lasse ich immer auf 1 weil ich früher damit seltsame Erfahrungen gemacht habe.
Das ist aber so lange her dass ich nicht mehr genau sagen kann was dabei schiefgelaufen ist.

[Perlsau]

Gerade ausprobiert, weil zuvor noch nie verwendet:

Setzt man MaxRecords auf einen Wert größer 0, wird in jedem Fall nur die gesetze Anzahl an Records geholt. Mehr geht nicht, bis MaxRecords auf einen größeren Wert gesetzt wurde.

Beläßt man dagegen MaxRecords auf 0 und setzt CacheSize z.B. auf 5 statt 1, sollte laut Online-Hilfe weitere Datensätze erst nachgeladen werden, nachdem sie angefordert wurden. Bei Aktivieren der Datenmenge sollten daher nur 5 Datensätze im Puffer stehen. Leider hab ich keine Ahnung, wie man das nachprüfen kann, denn beim erstmaligen Abruf von RecordCount fordert man ja gleich mal alle Datensätze an.

In der Online-Hilfe wird der Puffer auch als Zwischenspeicher beschrieben, der keine Datensätze enthalten soll, "die von anderen Benutzern der Daten gleichzeitig vorgenommen wurden" – doch m.W.n. gilt das generell für alle im Speicher von Datasets existierenden Datenmengen.

Ich gehe daher davon aus, daß es sich bei CacheSize einfach um die Menge an Datensätzen handelt, die bei Bedarf nachgeladen werden: Sobald man hinter den letzten geladenen Record kommt, werden weitere – in meinem Beispiel 5 – Datensätze nachgeladen. Meine Vermutung finde ich durch diesen Beitrag bei StackOverFlow bestätigt:

CacheSize

Delphi's and ADO's default cache size for a RecordSet is 1. That's 1 record. This works in combination with the cursor type. The cachesize tells the RecordSet how many records to fetch and store at a time.

When you issue a command like Next (really MoveNext in ADO) with a cache size of 1, the RecordSet only has the current record in memory, so when it fetches that next record, it must request it from the provider again. If the cursor is not Static, that gives the provider the opportunity to get the latest data before returning the next record. So, a size of 1 makes sense for Keyset or Dynamic, because you want the provider to be able to get you the updated data.

Obviously, with a value of 1, there's communication between the provider and RecordSet each time move the cursor. Well, that's overhead that we don't want if the cursor type is static. So, increasing your cache size will reduce the number of round trips between the RecordSet and the provider. This also increases your memory requirements, but it should be faster.

Also note that with a cache size greater than 1 for Keyset cursors, if the record that you want is in the cache, it won't request it from the provider again, which means that you won't see the updates.

[MrSpock]

Ich kann das so nicht bestätigen, was aber durchaus an der ODBC Treiber Installation von SAGE KHK New Classic Line liegen kann.

Ich habe in der ADOTable Komponente einmal sowohl MaxRecords als auch CachSize auf 100 gesetzt. Dann bin ich die Tabelle in einer Schleife durchlaufen und habe alle ca. 5400 Datensätze lesen können. In sofern wird MaxRecords hier nicht als wirklich harte Grenze interpretiert.

Mein Problem ist, dass eine Anwendung beim Kunden seit der Umstellung auf die neue New Classic Line beim Lesen der Kundetabelle einfach mit dem Fehler "Out of memory" hängen bleibt. Das passiert auf meinem älteren Rechner nicht. Beide nutzen Win 7 64 Bit. Es scheint so zu sein, dass beim Aufruf von RecordCount die gesamte Tabelle in den Speicher geladen wird, bzw. das System versucht diese zu laden. Ich habe deshalb RecordCount durch eine ADO SQL Abfrage an den Server ersetzt. Außerdem habe ich CacheSize auf 100 gesetzt und MaxRecords jetzt wieder von 100 auf 0 zurückgesetzt.

Bin gespannt, ob es das Problem löst. :stupid:

[Perlsau]

Zitat:

Zitat von MrSpock (Beitrag 1254097)

Ich kann das so nicht bestätigen, was aber durchaus an der ODBC Treiber Installation von SAGE KHK New Classic Line liegen kann.

... was ich wiederum mangels "SAGE KHK New Classic Line" nicht beurteilen kann ...

Zitat:

Zitat von MrSpock (Beitrag 1254097)

Ich habe in der ADOTable Komponente einmal sowohl MaxRecords als auch CachSize auf 100 gesetzt. Dann bin ich die Tabelle in einer Schleife durchlaufen und habe alle ca. 5400 Datensätze lesen können. In sofern wird MaxRecords hier nicht als wirklich harte Grenze interpretiert.

Eine Schleife benötigte ich bislang nicht, um Datensätze via TAdoTable zu lesen. Gewöhnlich setzt man in TAdoTable doch einfach die Connection und wählt dann eine der verfügbaren Tabellen aus. Ich habe das hier mit einer Sichten-Tabelle (View) im SQL-Server (Treiber: SQLOLEDB.1) unter Delphi 2009 getestet. Wenn ich MaxRecords auf 5 stelle, erhalte ich nur die ersten 5 Records und komme da auch nicht an weitere Records ran, egal was ich anstelle.

Könntest du das mit der Schleife mal etwas näher erläutern?

Zitat:

Zitat von MrSpock (Beitrag 1254097)

Mein Problem ist, dass eine Anwendung beim Kunden seit der Umstellung auf die neue New Classic Line beim Lesen der Kundetabelle einfach mit dem Fehler "Out of memory" hängen bleibt. Das passiert auf meinem älteren Rechner nicht. Beide nutzen Win 7 64 Bit. Es scheint so zu sein, dass beim Aufruf von RecordCount die gesamte Tabelle in den Speicher geladen wird, bzw. das System versucht diese zu laden. Ich habe deshalb RecordCount durch eine ADO SQL Abfrage an den Server ersetzt. Außerdem habe ich CacheSize auf 100 gesetzt und MaxRecords jetzt wieder von 100 auf 0 zurückgesetzt.

Scheint so, als ob es ich um sehr große Tabellen handelt, eventuell mit großen Blob-Feldern? Defaultmäßig steht CacheSize auf 1, was bedeutet, daß bei Anforderung immer nur ein weiterer Datensatz geholt (fetched) wird. Möglicherweise hilft es in deinem Fall, CacheSize auf einem eher niedrigen Wert zu belassen statt gleich 100 Datensätze auf einmal in den Cache (Speicher) zu laden.

Die Ado-Komponenten scheinen mir, der ich durch FibPlus und IbDac verwöhnt bin, doch eher unkomfortabel zu sein. Dessen ungeachtet kann ich selbst auch nicht immer auf Ado verzichten, weil mir das Geld für bessere, modernere Kompos fehlt. Beim nächsten finanziellen Überschuß schaffe ich mir UniDac an, damit kann ich dann wohl die meisten Datenbanken abdecken.

[MrSpock]

Zitat:

Zitat von Perlsau (Beitrag 1254119)

Scheint so, als ob es ich um sehr große Tabellen handelt, eventuell mit großen Blob-Feldern? Defaultmäßig steht CacheSize auf 1, was bedeutet, daß bei Anforderung immer nur ein weiterer Datensatz geholt (fetched) wird. Möglicherweise hilft es in deinem Fall, CacheSize auf einem eher niedrigen Wert zu belassen statt gleich 100 Datensätze auf einmal in den Cache (Speicher) zu laden.

Die Ado-Komponenten scheinen mir, der ich durch FibPlus und IbDac verwöhnt bin, doch eher unkomfortabel zu sein. Dessen ungeachtet kann ich selbst auch nicht immer auf Ado verzichten, weil mir das Geld für bessere, modernere Kompos fehlt. Beim nächsten finanziellen Überschuß schaffe ich mir UniDac an, damit kann ich dann wohl die meisten Datenbanken abdecken.

Nein, die Tabellen sind gar nicht wirklich groß und enthalten keine BLOB Felder, dennoch bricht das Programm weiter mit "Out of Memory" ab. Bei mir, wo die Tabellen alle auf dem lokales Rechner sind, funktioniert alles einwandfrei. Beim Kunden, wo die Tabellen auf verschiedenen Servern liegen, kommt es zu dem Fehler.

Ich weiß noch nicht genau wann der fehler auftritt. Das Öffnen der Tabelle (mit Open) funktioniert ohne Probleme. Dann frage ich mit der ADO SQL Abfrage die Anzahl der Datensätze in der Tabelle ab. Auch das funktioniert. Dann laufe ich in einer Schleife bis zum EOF durch. Offensichtlich wird aber beim Zugriff auf den ersten Datensatz irgendwie der Fehler ausgelöst. :shock:

[Dejan Vu]

War da nicht etwas mit client/serverseitigen Cursors (was ist nur die Mehrzahl von Cursor? :gruebel:)

Zitat:

Das Öffnen der Tabelle (mit Open) funktioniert ohne Probleme. Dann frage ich mit der ADO SQL Abfrage die Anzahl der Datensätze in der Tabelle ab.

Andersherum geht es auch.

Ich kenne beim ersten Zugriff auf ein ADO-Record bzw. Feld eine Nil-Exception, aber das war ADO 2.6 (glaube ich). Dieses Problem sollte nicht mehr auftreten.

Welche DB? Access?

[Perlsau]

Zitat:

Zitat von Dejan Vu (Beitrag 1254151)

Welche DB? Access?

Steht doch bereits oben im Eröffnungsposting.

[Dejan Vu]

Zitat:

Zitat von Perlsau (Beitrag 1254154)

Zitat:

Zitat von Dejan Vu (Beitrag 1254151)

Welche DB? Access?

Steht doch bereits oben im Eröffnungsposting.

Sieht man beim Schreiben nicht. :oops:

[MrSpock]

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:

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

[MrSpock]

Es sind 5400 Datensätze (KundenTabelle). Ich habe dann ein ADODataSet genommen und wie oben beschrieben nur Blöcke eingelesen. Der erste Block sollte weniger als 500 Datensätze umfassen. Dann öffne ich das DS und lasse es in einem DBGrid anzeigen. Die Daten erscheinen und dann kommt die "Out of Memory" Fehlermeldung. :evil: (Bei weniger als 500 Kundendatensätze !?)

[Perlsau]

Mir ist das Verhalten des AdoDataSet äußerst suspekt. Schon allein die Tatsache, daß das Property MaxRecords offensichtlich nicht von deinem ODBC-Spezialtreiber übernommen und ausgeführt wird, spricht dafür, daß dort irgendwo der Wurm drin ist. Zumindest erhielt ich bislang noch niemals eine derartige Fehlermeldung, weder beim Einsatz mit MSSQL noch mit MySQL. Und mit beiden DBMS hatte ich bereits Tabellen mit etlichen Millionen Datensätzen problemlos via Ado angezeigt bekommen. Ich bin mir daher ziemlich sicher, daß das Problem nicht durch die Ado-Komponenten hervorgerufen wird. Einige Dinge sind mir bei deinem Problem noch unklar:

1. Besteht das Out-Of-Memory-Problem seit Entwicklungs-Beginn? Oder ist es erst im Laufe der weiteren Entwicklung aufgetreten?
   
2. Falls nicht, würdest du in Betracht ziehen, rein zum Testen einmal ein Test-Projekt anzulegen und zu versuchen, die Problemsituation nachzustellen? Einfach eine TAdoConnection, ein TAdoDataSet und ein DBGrid aufs Formular pflanzen, zur Laufzeit verbinden und anzeigen lassen.
   
3. Wenn beim Testprojekt derselbe Fehler wieder erscheint, würde ich mich bei Sage einmal erkundigen, welche Alternativen existieren: Gibt es noch andere DB-Komponenten, um auf dieses ganz spezielle DBMS zugreifen zu können?
   
4. Sollte der Fehler im Testprojekt nicht auftreten, ist während der Weiterentwicklung der Anwendung was schiefgelaufen. Ich hatte z.B. kürzlich ein ziemlich vermurkstes Projekt von XE2 nach 2009 portieren wollen und danach seltsame Fehlermeldungen ebenfalls im Zusammenhang mit Ado-Komponenten erhalten. Erst nachdem ich sämtliche Ado-Komponenten in Delphi2009 erstmal aus dem Datenmodul entfernt und danach aus der Toolpalette wieder neu gesetzt hatte, funktiernierten sie einwandfrei.
   
5. Gibt es bei Sage eine Community bzw. ein Forum, wo man nach ähnlichen Problemen recherchieren könnte?
   
6. Hast du dieses Problem bereits mit dem Support von Sage besprochen?

Mehr fällt mir im Augenblick auch nicht dazu ein.

[MrSpock]

Zitat:

Zitat von Perlsau (Beitrag 1254375)

Mir ist das Verhalten des AdoDataSet äußerst suspekt. Schon allein die Tatsache, daß das Property MaxRecords offensichtlich nicht von deinem ODBC-Spezialtreiber übernommen und ausgeführt wird, spricht dafür, daß dort irgendwo der Wurm drin ist. Zumindest erhielt ich bislang noch niemals eine derartige Fehlermeldung, weder beim Einsatz mit MSSQL noch mit MySQL. Und mit beiden DBMS hatte ich bereits Tabellen mit etlichen Millionen Datensätzen problemlos via Ado angezeigt bekommen. Ich bin mir daher ziemlich sicher, daß das Problem nicht durch die Ado-Komponenten hervorgerufen wird. Einige Dinge sind mir bei deinem Problem noch unklar:

1. Besteht das Out-Of-Memory-Problem seit Entwicklungs-Beginn? Oder ist es erst im Laufe der weiteren Entwicklung aufgetreten?
   
2. Falls nicht, würdest du in Betracht ziehen, rein zum Testen einmal ein Test-Projekt anzulegen und zu versuchen, die Problemsituation nachzustellen? Einfach eine TAdoConnection, ein TAdoDataSet und ein DBGrid aufs Formular pflanzen, zur Laufzeit verbinden und anzeigen lassen.
   
3. Wenn beim Testprojekt derselbe Fehler wieder erscheint, würde ich mich bei Sage einmal erkundigen, welche Alternativen existieren: Gibt es noch andere DB-Komponenten, um auf dieses ganz spezielle DBMS zugreifen zu können?
   
4. Sollte der Fehler im Testprojekt nicht auftreten, ist während der Weiterentwicklung der Anwendung was schiefgelaufen. Ich hatte z.B. kürzlich ein ziemlich vermurkstes Projekt von XE2 nach 2009 portieren wollen und danach seltsame Fehlermeldungen ebenfalls im Zusammenhang mit Ado-Komponenten erhalten. Erst nachdem ich sämtliche Ado-Komponenten in Delphi2009 erstmal aus dem Datenmodul entfernt und danach aus der Toolpalette wieder neu gesetzt hatte, funktiernierten sie einwandfrei.
   
5. Gibt es bei Sage eine Community bzw. ein Forum, wo man nach ähnlichen Problemen recherchieren könnte?
   
6. Hast du dieses Problem bereits mit dem Support von Sage besprochen?

Mehr fällt mir im Augenblick auch nicht dazu ein.

Das Out-Of-Memory Problem besteht seid dem Upgrade von New CL 2013 auf die New CL 2014. Ich habe dazu in meinem Programm "nur" einen neuen ODBC Eintrag ausgewählt, der auf die CL 2014 verweist. Das Programm habe ich anschließend bei mir getestet und es lief sofort durch. Beim Kunden kam dann der Fehler.

Das mit dem Testprogramm habe ich gestern gemacht. Ich greife dabei mit 3 Methoden auf die Tabellen zu. Nämlich mit ADOTable (wie bisher), mit ADODataSet und dem SQL Statement "SELECT * FROM Kunden" und als 3. Möglichkeit mit einem ADODataSet bei dem ich die Datenmenge über die KundenNummer einschränke, damit nicht alle 5400 Datensätze auf einmal geholt werden. Selbst die 3. Methode führt beim Kunden zum "Out of Memory" Fehler, obwohl hier nur noch ca. 500 Datensätze geholt werden.

Bei Sage und auch im Internet habe ich schon gesucht. Die einzige zusätzliche Info, die ich gefunden habe (neben der, dass es Probleme beim Einselsen von mehreren Millionen (!) Datensätze oder extrem vielen großen Blob Feldern gibt), ist dass es an den Einstellungen des ODBC Treibers liegen kann.

Der ODBC Treiber erlaubt nicht viele Einstellungen.

Übrigens können die Daten über Excel und dem Zugriff auf den ODBC Treiber problemlos beim Kunden gelesen werden!

In der Treibereinstellung muss man eine Stationskonfigurationsdatei angeben. Hier gibt es einen Unterschied zu meiner Testumgebung. So nutze ich ein Einplatzsystem und der Kunde ein Mehrplatzsystem. Da suche ich im Moment die Ursache.

Interessanterweise habe ich einen MA gebeten, das Testprogramm direkt auf dem Server zu starten, um das Netztwerk als Ursache auszuschließen. Auch hier kommt der Fehler!

[Perlsau]

Welche Unterschiede bestehen zwischen deinem Rechner und dem Server des Kunden? Betriebssystem? Ausstattung? Wenn er MA die Anwendung dort direkt auf dem Server startet, entspricht das dann weitgehend deiner Testumgebung?

[MrSpock]

Beide Rechner laufen auf Win 7 64 Bit. Meiner ist etwa 3 Jahre alt, der des Kunden ist neu.

Bei mir läuft SAGE CL im Einzelbetriebsmode, beim Kunden der Mehrbenutzermode. Das sind die Unterschiede, die mir einfallen. Der Mitarbeiter wird gleich alle aus dem System verbannen und das System im Einzelplatzmode starten und dann nochmal das Testprogramm laufen lassen.

Ich frage mich, warum der Zugriff über ADO -> ODBC den genannten Fehler erzeugt (beim Kunden), der Zugriff über EXCEL -> ODBC aber funktioniert. Nutzt Excel nicht auch ADO für den Zugriff auf einen ODBC Treiber ?

[arnof]

Zitat:

Zitat von MrSpock (Beitrag 1254366)

Es sind 5400 Datensätze (KundenTabelle). Ich habe dann ein ADODataSet genommen und wie oben beschrieben nur Blöcke eingelesen. Der erste Block sollte weniger als 500 Datensätze umfassen. Dann öffne ich das DS und lasse es in einem DBGrid anzeigen. Die Daten erscheinen und dann kommt die "Out of Memory" Fehlermeldung. :evil: (Bei weniger als 500 Kundendatensätze !?)

Also, da stimmt was mit einem Langtextfeld nicht!

MYSQL ODBC Treiber hatte schon immer einen Bug, das der ein Langtextfeld um eins versetzt meldet (DataSet.Field[x].DataType).

Deshalb mach ich bei mir erst ein Dummyfeld und danach alle Memofelder :wink:

So wenn er in einem Langtextfeld viel drin hat, so sagt der es währe ein varcharfeld, diese sind aber in Delphi auf eine max Länge von x Chars angelegt und es kommt zum Problem.

Wenn Du dein Problem erkennen willst, dann mach aus SELECT * FROM xxx -> SELECT x,y,z from und teste mit welchem Feld das zusammenhängt!

[Jumpy]

Nur Spekulation: Könnte das vllt. auch was 64bit vs. 32bit Problem sein? Excel ist ja vllt. 64bit der Treiber vllt. auch, dein Programm aber nicht?

[arnof]

Zitat:

Zitat von Jumpy (Beitrag 1254390)

Nur Spekulation: Könnte das vllt. auch was 64bit vs. 32bit Problem sein? Excel ist ja vllt. 64bit der Treiber vllt. auch, dein Programm aber nicht?

Wenn da das Problem währe würde es gar nicht gehen!

[Dejan Vu]

Moment. Da könnte aber etwas dran sein. Es gibt zumindest zwei ODBC-Einstellungssätze (Registry) in einem 64bit-System. Ich bin auch neulich drauf reingefallen, als ich (ja ja) eine BDE-Installation auf einem 64-bit-System anfassen musste:

ODBC über Systemsteuerung => 64-bit (und entsprechende Einstellungen in der Registry)
ODBC über BDE-Admin => 32-bit (und -ätsch- andere Einstellungen in der Registry)

[Jumpy]

Andere Abfragen scheinen ja zu gehen und in sofern hat arnof wahrscheinlich recht. Wenn der Treiber gar nicht passen würde, würden auch andere Abfragen nicht gehen, woran ich nicht gedacht hatte. Ich hatte nämlich ein Ähnliches Szenario wie Dejan im Kopf.

[Dejan Vu]

Schon klar. Aber es ist ein (Konfigurations-)unterschied vorhanden. Der Treiber kann ja funktionieren, aber wenn er unter 64-bit (EXCEL) anders konfiguriert ist, als unter Sage/Delphi-Tool (32-bit), wäre das eine Möglichkeit.

[arnof]

Zitat:

Zitat von Dejan Vu (Beitrag 1254415)

Schon klar. Aber es ist ein (Konfigurations-)unterschied vorhanden. Der Treiber kann ja funktionieren, aber wenn er unter 64-bit (EXCEL) anders konfiguriert ist, als unter Sage/Delphi-Tool (32-bit), wäre das eine Möglichkeit.

Deshalb hatte ich ja mal nach dem Connectionstring gefragt, da kann man alle Parameter übergeben :roll:

[Dejan Vu]

Zitat:

Zitat von arnof (Beitrag 1254416)

Deshalb hatte ich ja mal nach dem Connectionstring gefragt, da kann man alle Parameter übergeben :roll:

Logisch. Ich war noch so auf dem blöden BDE gebürstet, hatte ich komplett vergessen.

[MrSpock]

Zitat:

Zitat von Jumpy (Beitrag 1254390)

Nur Spekulation: Könnte das vllt. auch was 64bit vs. 32bit Problem sein? Excel ist ja vllt. 64bit der Treiber vllt. auch, dein Programm aber nicht?

Nein, man muss das ODBC32ADM.exe Programm auf 64 Bit Systemen verwenden. Das haben wir auch gemacht.

[MrSpock]

Zitat:

Zitat von arnof (Beitrag 1254354)

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)

Wie gesagt, es sind 5400 Datensätze, aber wir haben uns den Taskmanager angeschaut. Das System ADO -> ODBC -> KHK MySQL saugt sich voll. Der Speicherverbrauch geht auf 1.8 GB, dann kommt die Fehlermeldung. Selbst wenn ich nur ca. 500 Datensätze einlese (eingeschränkt über die KundenNummer) kommt der Speicherfehler!

Wieso ist das Verhalten anders als bei mir auf dem Einzelplatzrechner :-(

[arnof]

Zitat:

Zitat von MrSpock (Beitrag 1254433)

Zitat:

Zitat von arnof (Beitrag 1254354)

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)

Wie gesagt, es sind 5400 Datensätze, aber wir haben uns den Taskmanager angeschaut. Das System ADO -> ODBC -> KHK MySQL saugt sich voll. Der Speicherverbrauch geht auf 1.8 GB, dann kommt die Fehlermeldung. Selbst wenn ich nur ca. 500 Datensätze einlese (eingeschränkt über die KundenNummer) kommt der Speicherfehler!

Wieso ist das Verhalten anders als bei mir auf dem Einzelplatzrechner :-(

Weiter oben hatte ich dir die Lösung geschrieben!

[MrSpock]

Danke nochmal für den Hinweis. Hatte deinen Beitrag tatsächlich übersehen. :stupid:

Habe mein Testprogramm jetzt gemäß deiner Empfehlung angepasst und es scheint zu funktionieren! Ich habe jetzt nur die Spalten abgerufen, die ich auchtatsächlich benötige. Die letzte Bestätigung brauche ich noch von einem Mitarbeiter, aber es sieht erstmal gut aus!

Unverständlich bleibt für mich, dass der Fehler im ODBC Treiber wohl noch nicht bekannt ist und dass er nur im Kundennetz, aber nicht auf meinem Einplatzrechner auftritt. :gruebel:

[arnof]

Das Problem hängt an Inhalt des Feldes und tritt nur auf, wenn eine kritische Länge überschritten wird. Wenn Du ein Backup der Datenbank holst, dann wirst Du es sehen!


Hier mal mein Beispiel wie ich das gelöst habe:

Delphi-Quellcode:

 Unit Data.WIN.ADODB

procedure TCustomADODataSet.InternalInitFieldDefs;
...

  procedure AddFieldDef(F: Field; FieldDefs: TFieldDefs);
  var
    ....
    // echte Abfrage
    FieldType := ADOTypeToFieldType(F.Type_, F.Precision, F.NumericScale, EnableBCD);
    // 
    if (F.Name='Problemfeldname') then begin
     FieldType := ftMemo;
    end;

[MrSpock]

Das habe ich jetzt nicht verstanden. :stupid:

Wo bzw. wie sehe ich das in einem Backup der DB?

Und die Lösung verstehe ich auch nicht. Hast du eine Neue ADO Komponente von der alten abgeleitet und dort die angegebene Methode überschrieben?

[Sir Rufo]

Zitat:

Zitat von arnof (Beitrag 1254307)

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:

Nein der ODBC-Treiber überwacht das nicht, aber das womit dieser ODBC-Treiber spricht ... und ich vermute mal, der wird eben nicht direkt mit dem MySQL-Server sprechen ;)

Code:

CL-ODBC-Treiber <-> CL-Server <-> MySQL-Server <-> CL-Datenbank

statt

Code:

MySQL-ODBC-Treiber <-> MySQL-Server <-> CL-Datenbank

Insofern wird der ConnectionString auch sehr unspannend sein, da dieser nur Einstellungen für den CL-ODBC-Treiber beinhalten kann und die haben nun mal nix mit dem MySQL-ODBC-Treiber zu schaffen.