Phänomen rückwärtsblättern SQL

[woodstock99]

Hallo zusammen.

Ich habe ein SQLRPGLE programmiert bei dem es möglich ist 5 Sortierungswege einzugeben.

Alles funktionieren nur beim Sortieren nach Namen tritt ein Phänomen auf.

Beispiel:
Wenn ich mich auf die Namen mit dem Anfangsbuchstaben B positioniere, einmal vorwärts blättere und wieder zurück blättere, positioniert sich mein Cursor falsch.


Anzeige Subfile

Name
B & S GASTRONOMIEBEDARF
B.B. TRADE S.R.L.
B.B. TRADE S.R.L.
B.B. TRADE S.R.L.
BACHER HERMANN
BACHER OTTO
BACKRING NORD
BACKRING NORD
BACKRING NORD
BADE GMBH
BADE GMBH
BADORF GMBH & CO.KG
BADORF GMBH & CO.KG
BADORF GMBH & CO.KG
BAEHSEL KARL
BAEKO SUEDWUERTTEMBERG EG
BAEKO SUEDWUERTTEMBERG EG


nach einmal vorwärtsblättern


BAETZ - PORZELLANHAUS
BAETZ - PORZELLANHAUS
BAETZ - PORZELLANHAUS
BAEUCKE GMBH & CO. KG
BAEUCKE GMBH & CO. KG
BAHRAJA TRADING L.L.C.
BAHRAJA TRADING L.L.C.
BAHRAJA TRADING L.L.C.
BAIER - HAUSHALTWAREN
BAK - BACK-KONTOR GMBH
BAK - BACK-KONTOR GMBH
BAK - BACK-KONTOR GMBH
BAK - BACK-KONTOR GMBH
BAK - BACK-KONTOR GMBH
BALZER - INH.: A. KAMM
BANHOLZER HOTELBEDARF AG
BANTEL GMBH - FACHKAUFHAUS


und jetzt wieder rückwärtsblättern

ANDRIESSE & CO. B.V.
ANDRIESSE & CO. B.V.
ANDRIESSE & CO. B.V.
ANGERMUELLER & CO. KG
ANGERMUELLER & CO. KG
ANTIK-STUEBCHEN
ANTIK-STUEBCHEN
APEL GMBH
APETITO AG
APFELBOECK E.K.
ARAMARK GMBH
ARAMARK GMBH
ARAMARK GMBH
ARAMARK GMBH
ARAMARK GMBH
ARINK - INH.: RUTH HEEMANN
ARKIETE - JSC



normalerweise müsste er

B & S GASTRONOMIEBEDARF
B.B. TRADE S.R.L.
B.B. TRADE S.R.L.
B.B. TRADE S.R.L.
BACHER HERMANN
BACHER OTTO
BACKRING NORD
BACKRING NORD
BACKRING NORD
BADE GMBH
BADE GMBH
BADORF GMBH & CO.KG
BADORF GMBH & CO.KG
BADORF GMBH & CO.KG
BAEHSEL KARL
BAEKO SUEDWUERTTEMBERG EG
BAEKO SUEDWUERTTEMBERG EG
wieder anzeigen. macht er aber nicht.


ich positioniere mich mit fetch relativ - (anzahl datensätze) ( in dem fall -34)


Bei den anderen Sortierkriterien (Betrag,Datum usw.) funktioniert mein Programm einwandfrei. Es werden die gleichen Routinen durchlaufen!!!


Muß ehrlich sagen ich kapier es nicht warum er in diesem Fall nicht 34 Sätze zurückliest sondern sogar ganze 78...

Hab auch schon gedebuged und im Feld

anzahl Datensätze steh -34 . Also müsste er ja wieder richtig positionieren oder.


Sortiert SQL intern irgendwie anders bei Alphanumwerten ??

Kann es sein das er bei doppelten ALPHA-Werten

z.b:

BADORF GMBH & CO.KG
BADORF GMBH & CO.KG
BADORF GMBH & CO.KG

diese 3 Sätze nur als einen ansieht????????

Kann eigentlich auch nicht sein weils z.b beim Buchstaben z rückwärtsblättern auf w einwandfrei funktioniert (Da ist der Name auch öfters als einzelner Datensatz vorhanden.

Da liest er schön brav..

Das gibts doch net oder???
Bei manchen Buchstaben funktionierts und von b und a nicht....

[woodstock99]

Der Hit.

Wenn ich es mit

do 34
fetch prior
enddo

mache macht er es richtig.

aber warum geht das nicht mit fetch relativ -34??
Da positioniert er falsch!

[Robi]

Hi,
ich hab zwar keine Idee warum das so ist.
M.e. ist die Idee des Subfiles die, das das Rückwärtsblättern nicht codiert werden muß, sondern vom SF selber gemacht wird. Nur bei extremen aktualitätsbedatf sollte mann immer neu lesen.
Gruß
Robi

[woodstock99]

hmmm.
ja da ist eine erklärung schwer zu finden.
wie gesagt ich kapiers auch net warum das des so ist obwohl es mich brennend interessieren würde.

ich muß leider die daten immer neu lesen aus verschiedenen gründen.

aber rein vom logischen her hat ja das subfile nix mit dem rückwärtslesen des cursors zu tun :).....


aber trotzdem danke für deine antwort.

[Fuerchau]

Bist du denn sicher, dass du auch tatsächlich so weit vor geblättert hast ?

Wie ist der Cursor definiert ?

[woodstock99]

mein cursor :

C/EXEC SQL
C+ PREPARE SEL FROM : SQLBEFEHL
C/END-EXEC
*
C/EXEC SQL
C+ DECLARE MYCUR SCROLL CURSOR FOR SEL
C/END-EXEC
*
C/EXEC SQL
C+ OPEN MYCUR
C/END-EXEC



c/EXEC SQL
C+ FETCH RELATIVE : readzurueck FROM MYCUR INTO : VIEWFETCH :ANZARRAY
c/END-EXEC



wie soweit vorgeblättert??
ich habe einmal vorwärts und einmal rückwarts und beim rückwärtsblättern geht er 78 sätze mit dem cursor zurück obwohl readzurueck (-34) beim fetch relativ befehl steht.


wenn ich

do readzurueck
FETCH PRIOR FROM MYCUR INTO : VIEWFETCH :ANZARRAY
enddo

mache

klappts einwandfrei.


hier noch meine Sortierungen

%subst(sqlbefehl:l1+2) ='order by RECDAT' funktioniert mit fetch relativ
%subst(sqlbefehl:l1+2) ='order by ENDBET' funktioniert mit fetch relativ
%subst(sqlbefehl:l1+2) ='order by RECHNU' funktioniert mit fetch relativ
%subst(sqlbefehl:l1+2) ='order by OFFPOS' funktioniert mit fetch relativ
%subst(sqlbefehl:l1+2) ='order by FNAMEN' funktioniert teilweise mit fetch relativ :(((((

Also wie gesagt ich check es nicht :(((.

[Kaufmann]

Du liest die Werte für dein Subfile jedesmal neu und schreibst es neu. Damit setzt du die Positionierung wieder auf den Anfangswert. Oder hast Du ein statisches Subfile?

[woodstock99]

ich lese nicht die werte von der subfile sondern von einer view anhand eines sql-cursors. ich fülle die subfile nur .
entweder mit 17 sätzen oder mit dem rest (ende datensätze).

das hat meiner meinung nach überhaupt nix mit der subfile zu tun. es klappt ja auch bei den 4 anderen sortierkriterien. da ist was anderes im busch. wie gesagt beim sortierkriterium nach namen macht er es ja bei bestimmten buchstaben richtig und bei anderen falsch. wenn ich den sql befehl den ich mir zusmmengebastelt hab am system absetze bringt er mir die sätze in der richtigen reihenfolge.

beim vorwärtsblättern liest er auch richtig von der view. nur beim rückwärtsblättern positioniert er sich ab und zu total falsch (aber nur bei fetch relativ) obwohl im readrückwaerts der richtige wert enthalten ist. wenn ich es wie oben schon mal erwähnt mit fetch prior mache funzt das programm auch bei diesem sortierkriterium obwohl in readrückwärts beides mal derselbe wert steht.

eigentlich absoluter schwachsinn


den fetch relativ - 34

und

do 34
fetch prior
enddo

ergibt doch das gleich ergebnis


absolut komisch der fall...

ich glaub da hilft nur noch gott oder der der die etwas tiefere etage bevorzugt :)