[ADO] MaxRecords bzw. CacheSize

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