TUniQuery liefert falschen RecordCount

[Andidreas]

Hallo,

über eine TUniQuery mache ich einen ganz normalen

Code:

Select * From

auf eine SQLite Tabelle.
Wenn ich den RecordCount Abfrage liefert er mir ein falsches Ergebnis, mal sagt er ich habe 325 Datensätze in der Tabelle, mal 25, mal 850.
Die Tatsächlichen 870 Datensätze gibt er mir aber nie als RecordCount an.

Woran kann das liegen?

[jaenicke]

Wenn nicht alle Datensätze sofort abgerufen werden, "weiß" die Query noch gar nicht wie viele Datensätze es sind. Um das zu erzwingen kannst du (wenn es bei der Klasse dafür keine Einstellung gibt), ein Query.Last aufrufen und dann die Anzahl auslesen. Allerdings kann das eben ggf. auch deutlich länger dauern, wenn die Tabelle groß ist.

[Bentissimo]

Such mal in der UniDAC Hilfe nach "FetchRows".

[jaevencooler]

Moin, Moin,

Du kannst Dir auch mal die FetchOptions ansehen, da kannst Du einstellen wie die Daten von Deiner DB geholt werden sollen :

http://www.da-soft.com/anydac/docu/f...mfile=FAQ.html


Beste Grüße
Michael

[Andidreas]

Das mit den FetchRows habe ich auch gesehen...
Hier ist bei mir der Standard Wert von 25 eingetragen...

Das passt dann doch nicht zu den RecordCounts die mir die TUniQuery zurückliefert... oder doch?

[Bernhard Geyer]

Zitat von Andidreas:

Das passt dann doch nicht zu den RecordCounts die mir die TUniQuery zurückliefert... oder doch?

Doch. Deine Werte sind vielfache von 25 und der liefert dir die Anzahl der schon geholten Einträge.

[Perlsau]

Zitat von jaenicke:

... ein Query.Last aufrufen und dann die Anzahl auslesen.

Daneben bieten die Query-Komponenten von DevArt die Möglichkeit, in den Options das Property QueryRecCount auf True zu setzen. Damit wird bei jedem Select die Anzahl der Datensätze ermittelt. Kann natürlich ebenso wie ein Query.Last etliche Zeit in Anspruch nehmen.

Eine dritte Möglichkeit bestünde darin, in einer gesonderten Tabelle den RecordCount aller anderen Tabellen zu verwalten, eventuell mit einer StoredProcedure auf dem Laufenden halten ...

[nahpets]

Wenn ich den RecordCount einer Tabelle zwingend korrekt benötige mache ich einfach ein:

Code:

select count(*) as Anzahl from Tabelle

Das in einer extra Tabelle zu verwalten dürfte schnell recht aufwändig werden, da jedes Insert oder Delete dann diesen Verwaltungsschritt auslösen müsste und dann letztlich auch nur das Ergebnis des obigen SQL je Tabelle in der Verwaltungstabelle speichern müsste.

[Perlsau]

Zitat von nahpets:

Wenn ich den RecordCount einer Tabelle zwingend korrekt benötige mache ich einfach ein:

Code:

select count(*) as Anzahl from Tabelle

Und das wäre dann aus welchem Grund schneller als ein Query.Last?

Zitat von nahpets:

Das in einer extra Tabelle zu verwalten dürfte schnell recht aufwändig werden, da jedes Insert oder Delete dann diesen Verwaltungsschritt auslösen müsste und dann letztlich auch nur das Ergebnis des obigen SQL je Tabelle in der Verwaltungstabelle speichern müsste.

Bei einer Tabelle mit zahlreichen Spalten (große VarChars und etliche Blobs) und Millionen von Datensätzen kann das aber schon Geschwindigkeitsvorteile bringen, wenn es um das Ermitteln des RecordCount geht, denn es würde das Durchzählen ersparen. Was spräche denn dagegen, mittels entsprechender StoredProcedures, die von den Triggern AfterInsert und AfterDelete ausgelöst werden, diesen einen Eintrag vorzunehmen? Man könnte auf diese Weise sogar den RecordCount aller Tabellen auf dem aktuellen Stand halten, wenn es notwendig wäre. Ich bin mir sicher, daß bei sehr großen Datenbanken (z.B. denen der NSA oder auch denen der EU-Vorratsdatenspeicherung) solche Mechanismen angewendet werden.

[DeddyH]

Das kann ich mir nicht vorstellen. So etwas würde ja nur in solchen Datenbanken ansatzweise Sinn ergeben, die sehr oft abgefragt, aber eher selten aktualisiert werden. Alle anderen würden hingegen vermutlich merklich ausgebremst werden, da für jeden einzelnen zu löschenden oder einzufügenden Datensatz der Trigger feuern würde.