Anzahl der Datesätze bei SQLRPGLE

[ExAzubi]

Hallo zusammen,

ich mache ein

SELECT FLD1, FLD2, FLD3 from DAT1 INNER JOIN DAT2 ON FLD2=FLD5

als dynamischen SQL Statement

Gibt es irgendwo einen rückkehrcode in der SQLCA wo die Anzahl an ermittelten Sätzen zu finden ist?
Also 0 oder 4711 -->ein quasi COUNT(*)

Danke an alle Helfenden.

[Robi]

Fetcht du anschl. die Selektion in eine occur-ds?
Dann steht in sqlerrorcode5 (glaube ich, lange nicht mehr verwendet) die Anzahl tatsächlicher Sätze.

Hmm..
Irgendwie ist mir nicht ganz klar was genau du machst?

Robi

[andreaspr@aon.at]

Habs zwar jetzt nicht getestet, sollte aber mit der Get Diagnostics auch möglich sein.


Exec Sql Get Diagnostics :count = DB2_NUMBER_ROWS;

lg Andreas

[ExAzubi]

Also die ermittelten Sätze schiebe ich in eine OCCUR-DS.

Ich würde die Anzahl aber gerne haben um eine Info auszugeben, "Es wurden xxxx Sätze ermittelt."

Desweiteren wenn es über 10000 sein sollten, dann auch noch bescheid geben, das nicht alle Sätze angezeigt werden können.

Also nicht dramatischem, werde beide Lösungen mal probieren und dann berichten :)

[Fuerchau]

Der Select kann die Anzahl der Sätze leider nicht übergeben.
Diagnostics liefert auch nur bei Update/Delete die Anzahl der Sätze.

Möchtest du die Anzahl vorher wissen dann geht das auch dynamsich:

select count(*) as counter from
( fullselect )

Zu bedeneken ist hier lediglich, dass bei Tablescans die Abfragedauer dann verdoppelt wird!

[andreaspr@aon.at]

Diagnostics liefert auch nur bei Update/Delete die Anzahl der Sätze.

Das stimmt nicht ganz. Das was du meinst ist der Parameter ROW_COUNT. Bei DB2_NUMBER_ROWS wird die anzahl der Sätze der Result Table zurückgegeben (Bei Open und Fetch)

[Fuerchau]

OK, das hängt aber nun doch sehr stark vom verwendeten Select und Cursor-Type ab.
Nur wenn SQL alle Sätze tatsächlich gelesen hat (kein Index für Sortierfolge), der Cursor insensitive ist, o.ä. könnte da ein gültiger Wert drinstehen.


<DT class=bold>DB2_NUMBER_ROWS<DD>If the previous SQL statement was an OPEN or a FETCH which caused the size of the result table to be known, returns the number of rows in the result table. For SENSITIVE cursors, this value can be thought of as an approximation since rows inserted and deleted will affect the next retrieval of this value. If the previous statement was a PREPARE statement, returns the estimated number of rows in the result table for the prepared statement. Otherwise, the value zero is returned.
Also wirklich verlassen würde ich mich nicht darauf.
</DD>

[andreaspr@aon.at]

OK, das hängt aber nun doch sehr stark vom verwendeten Select und Cursor-Type ab.
Nur wenn SQL alle Sätze tatsächlich gelesen hat (kein Index für Sortierfolge), der Cursor insensitive ist, o.ä. könnte da ein gültiger Wert drinstehen.

Ich hab das Gefühl du suchst einen Grund das nicht verwenden zu können ;)

*) Auch WENN die Engine einen Index für Sortierung verwendet steht da ein gültiger Wert drinnen. Wo hast du das denn gelesen??

*) Auch WENN der Cursor SENSITIVE ist, steht da ein gültiger Wert drinnen (zum Zeitpunkt zu dem das Result-Set aufgebaut wurde!!).
Vor dem gleichen Problem stehst du beim
select count(*) as counter from
( fullselect )
Bzw. weist du bei dem count(*) noch weniger ob dein Result-Set danach dem entspricht was du vorher gelesen hast, da sich die Tabelle zwischen den beiden Statements schon längst geändert haben könnte. Also GERADE in solch einen Fall ist die Methode mit GET DIAGNOSTICS die Bessere!!!

[Robi]

hab mich vertan, gem. meiner alten doku, ist es sqlerrcode(3), nicht 5

Ohne es probiert zu haben

Robi

[B.Hauser]

hab mich vertan, gem. meiner alten doku, ist es sqlerrcode(3), nicht 5

Ohne es probiert zu haben

Robi

SQLER3 oder SQLERRCODE(3) gibt die Anzahl der Datensätze an, die bei einem Multiple-Row-Fetch ausgegeben werden oder, die bei einem Insert, Update oder Delete (ohne Cursor) hinzugefügt, geändert oder gelöscht wurden.
Entspricht dem Schlüssel-Wort ROW_COUNT, das von einem GET DIAGNOSTICS-Statement ausgegeben werden kann.

SQLER5 order SQLERRCODE(5) gibt an, ob bei einem Multiple Row Fetch noch weitere Zeilen vorhanden sind, d.h. wird 100 ausgegeben, gibt es keine weiteren Zeilen.
SQLER5 entspricht dem Schlüssel-Wort DB2_LAST_ROW, das von einem GET DIAGNOSTICS Statement ausgegeben werden kann.

Birgitta