Hallo,

wie kann ich nach dem Ausführen eines Query (FIBQuery, FIBPlus Komponenten) feststellen, ob bzw. wie viele Datensätze von dem Query betroffen sind? Sowas wie RecordCount bei TDataSet gibt es ja hier leider nicht...

Schau dir mal SELECT COUNT (PK) an

André

Dann müßte ich vor dem eigentlichen Query noch eins ausführen, um die Anzahl der REcords zu bestimmen, und genau das will ich eben nicht tun....

Der Jan hat folgendes geschrieben:

wie kann ich nach dem Ausführen eines Query (FIBQuery, FIBPlus Komponenten) feststellen, ob bzw. wie viele Datensätze von dem Query betroffen sind? Sowas wie RecordCount bei TDataSet gibt es ja hier leider nicht...

Demnach benutzt du FireBird oder Interbase.
Bei SQL-Datenbanken macht RecordCount i.d.R. keinen Sinn. Bei großen Datenmengen wird üblicherweise nur ein Teil der Datenmenge übertragen. Somit weiß der client oft gar nicht, wieviel Datensätze tatsächlich existieren. Außerdem könnte sich die Anzahl der Datensätze im Mehrbenutzerbetrieb ständig ändern. Allerdings hat natürlich auch jede Abfrage einen eigenen Cursor auf der DB, wodurch die Anzahl der Datensätze erst recht nicht mehr genau ist.
Mir ist natürlich halbwegs klar, was du willst, aber ich wollte kurz aufzeigen, warum die Anzahl der Datensätze nur eine Spielerei und nur selten sinnvoll ist.
Ich kenne die FIB-Komponenten nicht aus eigener Erfahrung. Aber evtl. kannst du über den Trick zum letzten Datensatz zu springen, an die Anzahl der Datensätze kommen. Geht natürlich nur, wenn es die Komponente die Eigenschaft RecNo (Datensatznummer) o.ä. kennt.

Hi,

Wie kommst du darauf, dass es RecordCount nicht gibt?

Zitat:

set poAskRecordCount in PrepareOptions to True (calc RecordCount as "select count(*) <select_sql_from_and_where_section>") -- Sincerely yours, Nikolai Voynov Devrace - software for developers! __________________________________ e-mail: nvoynov@devrace.com url : www.devrace.com/, www.fibplus.com/

alex

alex517 hat folgendes geschrieben:

Hi, Wie kommst du darauf, dass es RecordCount nicht gibt? Zitat: set poAskRecordCount in PrepareOptions to True (calc RecordCount as "select count(*) <select_sql_from_and_where_section>") -- Sincerely yours, Nikolai Voynov Devrace - software for developers! __________________________________ e-mail: nvoynov@devrace.com url : www.devrace.com/, www.fibplus.com/ alex

FIBPlus Developers Guide: ...TpFIBQuery is not a Descendant of TDataSet, it does not Cache any Records and that is why it has not the RecordCount Method...

Ich möchte, wie schon erwähnt, nicht noch extra ein SELECT COUNT ausführen.

Dummerweise gibt TFIBQuery.Current auch einen SQL-Descriptor zurück, wenn kein Record gefunden wurde, so scheidet diese Möglichkeit aus.

Eigentlich würde es für den Moment schon reichen, zu wissen, ob überhaupt ein Record gefunden wurde. Nur leider weiss ich nicht, wie.
Notfalls muß ich eben über COUNT gehen, aber ich würde gerne eine Extra-Abfrage vermeiden.

Ääähm. Jaaa....

hab gerade festgestellt, das es ein Property RecordCount gibt...
Allerdings lt. Doku: Returns the number of records currently fetched by the query
Aber es bringt mich auf jeden Fall viiiiel weiter.

Der Jan hat folgendes geschrieben:

Ääähm. Jaaa.... hab gerade festgestellt, das es ein Property RecordCount gibt... Allerdings lt. Doku: Returns the number of records currently fetched by the query Aber es bringt mich auf jeden Fall viiiiel weiter.

Die unsaubere Methode wäre dann ein Fetchen aller Datensätze der Menge anzustoßen. Vielleicht gibt es eine Funktion FetchAll. Dann hast Du den genauen RecordCount.

@jasocul: Bei RecordCount geht es immer nur darum, die Anzahl der Datensätze der aktuellen Abfrage zu ermitteln und die kann ja nicht von außen geändert werden

Der Jan hat folgendes geschrieben:

Eigentlich würde es für den Moment schon reichen, zu wissen, ob überhaupt ein Record gefunden wurde. Nur leider weiss ich nicht, wie.

Du glaubst anscheinend, ein Select würde die performance bremsen, oder ein Count oder was auch immer ? Da wäre ich mal nicht so zimperlich. Ich habe hier einen Fall, bei dem ich kurzerhand den allerersten Datensatz (@Alex: select first 1 ) lese, nur um die Feldgrößen (DisplayWidth) mit der Schriftgröße verrechne und an ein Stringgrid als Colwidth übergebe. Was solls ?

Oder beim Einfügen/Ändern. Da guck ich auch zuerst, ob ein DS schon da ist und handele dementsprechend ob einer da ist oder eben nicht. Wenn Du solche Select-Statements nicht selber machten willst, dann machts eben FIBplus. Da wird wohl schon was besser optimiert werden, aber viel mehr als 0,1 Nanosekunden sind an der Stelle wohl kaum zu holen. Und der Umweg RecordCount kostet dann eben wieder 0,2 Nanosekunden. Davon abgesehen zielt die Frage langsam in Richtung Stored Procedures. Guck Dir die mal an.