Große Datenmengen richtig verarbeiten bzw. Out of Memory

[p80286]

Zitat von Jasocul:

Nach einem Open kann es in einigen Fällen dazu kommen, dass EOF true ist.
Bekannt sind mir folgende Fälle:
- kein FetchAll
- Nur ein Datensatz in der Ergebnismenge
Das passierte mir in den Fällen auch nur sehr selten, aber ich mache immer ein First, seitdem ich mal Probleme damit hatte.

Es ist gut möglich, dass das Problem in neueren Delphi-Versionen nicht mehr existiert. Das letzte mal hatte ich das Problem mit XE2.

Interessant. Ich habe unter D7 / 2006 nie ein .First gebraucht und .EOF war false es sei denn es kam eine leere Menge zurück, da hatte ich wohl Glück!
(oder könnte es sein, daß die Qualität der DB-Komponenten nicht so konsistent ist wie wir es gerne hätten)

Gruß
K-H

[Jasocul]

Ich denke, das ist wie mit dem Vergleich einer Boolean Variablen auf True/False. Normalerweise läuft trotzdem alles korrekt.

Mir ist es einfach vor Jahren mal passiert und seitdem gehe ich den sicheren Weg.

[Delphi.Narium]

Mir ist es auch ganz selten mal passiert, das BoF, EoF "falsche" Werte lieferten.

Das liegt wohl weniger an den Komponenten, sondern an dem, was die Datenbank (oder irgendwas aus den Zwischenschichten, Clients, Treibern, wieauchimmer ...) da so an Infos "rausrückt".

Identische Komponenten, aber unterschiedliche Datenbanken können, wenn auch seeeeeehr selten, zu solchen Problemen führen.

Ja nach Datenbank kann es auch passieren, dass RecordCount identisch mit RecNo ist, solange man nur vorwärts scrollt (per Next). Beim Rückwärtsscrollen bleibt RecordCount auf der RecNo des höchsten, bisher erreichten, Datensatze. Scrollt man über den hinaus, steigt RecordCount solange auf RecNo, bis man einmal EoF erreicht hat.

So wie First zu einem korrekten EoF führen kann, kann Last zu einem korrekten RecordCount führen (wobei dann aber die gesamte Datenmenge geladen wird und das kann dauern).

Und wenn man (bei unverändertem Quelltext) den Datenbanktyp wechselt, kann es sein, dass das Problem weg ist.

Aber: Das ist mir in ca. 22 Jahren so 3 oder 4 Mal passiert. Es ist ein sehr selten auftretender Fehler.

Erlebt in Delphiversionen bis D7.

[p80286]

Zitat von Delphi.Narium:

Identische Komponenten, aber unterschiedliche Datenbanken können, wenn auch seeeeeehr selten, zu solchen Problemen führen.

Wo Du es beschreibst...gleiche DB, gleiche Komponente, zwei unterschiedliche ADO-Treiber

Gruß
K-H

[Delphi.Narium]

Zitat von p80286:

Zitat von Delphi.Narium:

Identische Komponenten, aber unterschiedliche Datenbanken können, wenn auch seeeeeehr selten, zu solchen Problemen führen.

Wo Du es beschreibst...gleiche DB, gleiche Komponente, zwei unterschiedliche ADO-Treiber

Gruß
K-H

Exakt.

Wenn man mal bei DB-Zugriffen "ungewöhnliches" Verhalten seitens seines Delphiprogrammes beobachtet:

Es kann sehr hilfreich sein, sich die Datenbankverbindung und die Treiber anzuschauen / anzupassen, statt im Programmquelltext mehr oder weniger verzweifelt nach Workarounds um festgestellte Probleme zu suchen.

Früher (zu BDE-Zeiten) konnte es durchaus hilfreich sein, beim Zugriff auf Oracle auch deren Treiber zu nehmen und nicht den von Microsoft, der (damals?) auf den Systemen schon vorhanden war.

Keine Ahnung, wie sich das bis heute so entwickelt hat, aber die Fehlermöglichkeiten zwischen eigenem Programm und Datenbank sollte man nie ausklammern.

@MichaelT

select * from ist eine Unsitte, die verboten gehört. Es wird nur das selektiert, was man auch benötigt -> kleinstmögliche Ergebnismenge, sowohl in Bezug auf die ausgewählten Spalten als auch auf die ausgewählten Zeilen.

Alles zu holen und dann im Programm nur das benötigte zu verarbeiten ist einfach nur schlecht.

[jobo]

Zitat von Delphi.Narium:

select * from ist eine Unsitte,..
..
Alles zu holen und dann im Programm nur das benötigte zu verarbeiten ist einfach nur schlecht.

[/quote]

Unsitte, nicht unbedingt
Alles zu holen ist tatsächlich schlecht.

Wenn hinter dem from eine definierte Datenquelle hängt (view), die Spalten und Zeilen wie gewünscht eingrenzt, finde ich es nicht problematisch.
Spaß macht es, wenn man die Datenquelle ändert und "Select *" in der Anwendung einfach die zusätzlichen (oder weniger) Daten liefert.
Dazu gehört allerdings eine eigene Feldverwaltung.

[Delphi.Narium]

Zitat von jobo:

Wenn hinter dem from eine definierte Datenquelle hängt (view), die Spalten und Zeilen wie gewünscht eingrenzt, finde ich es nicht problematisch.
Spaß macht es, wenn man die Datenquelle ändert und "Select *" in der Anwendung einfach die zusätzlichen (oder weniger) Daten liefert.
Dazu gehört allerdings eine eigene Feldverwaltung.

Naja, prinzipiell hast Du ja recht, aber, wenn einer eine identische Tabelle, 'ne identische View erstellt, aber "nur" die Spalten im Create in 'ner anderen Reihenfolge angibt, kannst Du bereits die ersten Probleme bekommen. i := qry.fields[1].AsInteger könnte schon scheitern, weil die hier ursprunglich erwartete Spalte eventuell eine andere Position bekommen hat und wir hier den Inhalt einer Zeichenkette bekommen und nicht den in Spalte 1 erwarteten Integer.

Und wenn man statt * die benötigten Spalten angibt, schreibt man zwar mehr, aber wenn davon eine Spalte "verlustig" gehen sollte, knallt das SQL, die Query beim Open, und nicht erst ein eventuell viel später erfolgender Zugriff auf die "verschwundene" Spalte.

Mag es halt, wenn Fehler möglichst nah an der Fehlerursache auftreten und wenn eine mögliche Fehlerursache im SQL liegen kann, dann möchte ich, dass das SQL mir "um die Ohren fliegt" und nicht erst die Verarbeitung der erhaltenen, aber nicht so erwarteten, Ergebnismenge.