PDA

View Full Version : CPF5008



Seiten : [1] 2

FragenFrank
03-07-07, 17:28
Nachrichten-ID . . . . : CPF5008 Bewertung . . . . . . : 30
Nachrichtenart . . . . : Hinweis
Sendedatum . . . . . . : 03.07.07 Sendezeit . . . . . . : 18:08:07

Nachricht . . . : Datensatz bereits in Subdatei der Datei ASWF01D in
Bibliothek GRUVLAOBJ vorhanden.
Fehlerbeseitigung: Die relative Satznummer ändern, die aktuelle Satznummer
fortschreiben oder die Subdatei löschen. Den Befehl wiederholen.


Liebe Kolleginnen und Kollegen,
mit dem obigen Fehler schlage ich mich heute bereits den ganzen Tag herum. Der Fehler erscheint beim ERSTMALIGEN WRITE auf das Subfile. Ich habe bereits im Debugger VOR dem Ausführen des WRITE die relative Satznummer geändert, und sowohl ein SFLCLR als auch gar ein SFLDLT ausgeführt, immer wieder erscheint CPF5008. Weiß hier jemand evtl. einen Rat?

Viele Grüße und schon mal vielen Dank

prs
03-07-07, 17:39
- Wie ist das Feld rel. Satznummer in der DSPF definiert?
- Subfile-Size?
- Wird im Pgm. der richtige Feldname verwendet?
- Stimmt die F-Karte?
Irgendwie schaut mir das so aus, als würde in der DSPF ein anderes Feld als im Pgm. für die rel. Satznummer verwendet.

FragenFrank
04-07-07, 07:53
Hallo PRS,
erstmal vielen Dank für das Feedback. Die F-Karte ist wie folgt definiert:


FASWF01D CF E WORKSTN
F KINFDS SCRFDS
F SRN007KSFILE SFL007


Und so sieht es im DSPF aus:

A R SCT007 SFLCTL(SFL007)
A*%%TS SD 20070703 154730 FDIE REL-V5R4M0 5722-WDS
A SFLSIZ(0003)
A SFLPAG(0001)
A OVERLAY
A CHANGE(49)
A N31 SFLDSP
A SFLINZ
A N31 SFLDSPCTL
A 31 SFLCLR
A 31 SFLDLT
A ROLLUP(28)
A BLINK
A CSRLOC(§§CRLN §§CRCL)
A §§CRLN 3S 0H
A §§CRCL 3S 0H
A SRN007 4S 0H SFLRCDNBR



Wie gesagt, ich bekomme die Meldung schon beim ERSTMALIGEN WRITE auf SFL007. SRN007 ist zu diesem Zeitpunkt 1.

Fuerchau
04-07-07, 10:43
Entferne SFLDLT !
Dies dient zum kompletten Löschen der SFL aus dem Speicher.
Da eine DSPF max. 12 gefüllte Subfiles unterstützt muss man eben SFLDLT verwenden und diese aus dem Speicher entfernen.
Normalerweise benötigt man dies nicht.

Dann:
SFILE in den F-Bestimmungen definert die Relative SNR beim WRITE/CHAIN/READ/READC und hat aber überhaupt nichts mit SFLRCDNBR zu tun !

Wähle hier 2 verschieden Felder.

FragenFrank
04-07-07, 11:20
so?

FDXX A R SCT007 SFLCTL(SFL007)
FDXX A*%%TS SD 20070703 154730 FDIE REL-V5R4M0 5722-WDS
FDXX A SFLSIZ(0003)
FDXX A SFLPAG(0001)
FDXX A OVERLAY
FDXX A CHANGE(49)
FDXX A N31 SFLDSP
FDXX A SFLINZ
FDXX A N31 SFLDSPCTL
FDXX A 31 SFLCLR
FDXX A ROLLUP(28)
FDXX A BLINK
FDXX A CSRLOC(§§CRLN §§CRCL)
FDXX A §§CRLN 3S 0H
FDXX A §§CRCL 3S 0H
FDXX A STR007 4S 0H SFLRCDNBR


F KINFDS SCRFDS
F SRN007KSFILE SFL007

Leider komme ich hiermit zu dem gleichen Ergebnis. SRN007 und STR007 haben zum Zeitpunkt des ersten WRITE auf das Subfile den Wert 1. Zuvor wird lediglich das Subfile-Control geschrieben (mit SFLCLR). Oder anders, mit SRN007 und STR007=1 wird einmalig in ein gecleartes Subfile geschrieben, und schon bekomme ich CPD5008.

Fuerchau
04-07-07, 12:25
Noch ein Problem:
SFLINZ wird nicht benötigt, da dieses die SFL mit SFLSIZ leeren Sätzen initialisiert !

FragenFrank
04-07-07, 12:40
Das hat etwas gebracht. Zumindest wird jetzt schon mal ein Datensatz angezeigt, und ich bekomme kein CPF5008 mehr.

Vielen, herzlichen Dank.

tarkusch
08-03-17, 13:39
Hallo,

mich plagt der selbige Fehler und ich werde nicht schlau draus.

Ich fülle einen Subfile über ein SqlStatement und der wird mir auch angezeigt.

Sobald ich im Sfl-Controller auf was bestimmte einschränke bekomme ich den Fehler.

Lt. Fetch von Sql sind Daten aber vorhanden.



FHPPGM01 CF E WORKSTN SFILE(SUBF1:C1RNR)
F SFILE(SUBF2:C2RNR)


D* Subfile 1
D i_subfdsp1 30 30n
D i_subfdspctl1 31 31n
D i_subfend1 32 32n
D i_subfclr1 33 33n
D i_chg_auswC1 34 34n


//Clear Subfile
i_subfdsp1 = *OFF;
i_subfdspctl1 = *OFF;
i_subfclr1 = *ON;
write SUBFCTL1;
i_subfclr1 = *OFF;
i_subfdspctl1 = *ON;
i_subfend1 = *Off;



A************************************************* *************************
A R SUBF1 SFL
A S1_P1PENR R H REFFLD(xxx yyy)
A DA_FARBE 1A P
A*
A S1_AUSW 1A B 8 2COLOR(GRN)
A S1_P1NAME R O 8 4REFFLD(xxx yyy)
A DSPATR(&DA_FARBE)
A S1_P1EIDT R O 8 30REFFLD(xxx yyy)
A DSPATR(&DA_FARBE)
A EDTCDE(9)
A S1_P1AUDT R O 8 41REFFLD(xxx yyy)
A DSPATR(&DA_FARBE)
A************************************************* *************************
A R SUBFCTL1 SFLCTL(SUBF1)
A SFLSIZ(0018)
A SFLPAG(0017)
A 30 SFLDSP
A 31 SFLDSPCTL
A 32 SFLEND(*MORE)
A 33 SFLCLR
A OVERLAY
A FRCDTA
A KEEP
A RTNCSRLOC(*RECNAME &SATZ1 &FELD1)
A CHANGE(34)
A*
A C1RNR 4S 0H SFLRCDNBR(CURSOR)
A SATZ1 10A H
A FELD1 10A H
A SDSPGM 10A O 1 2
A SDSUSR 10A O 1 13

Fuerchau
08-03-17, 15:36
Ich habe es mir schon immer angewöhnt, für jede Subfile per SFLRNR in den F-Bestimmungen ein Feld zu definieren.
Somit habe ich genau für jede SFL eine eigene Satznummer in der Hand.
Dann kann ich beim WRITE das SFLRNR-Feld entsprechend selber hochzählen.
Außerdem wird beim READ/READC in diesem Feld auch die Satz-Nr. geliefert um zu positionieren.
Ich brauche keine INFDS abfragen.

Nach dem SFLCLR wird die interne SFLRNR nicht unbedingt korrekt zurückgesetzt so dass der WRITE dann wohl scheitert.

tarkusch
08-03-17, 16:31
Ich mache aber ein Reset auf C1RNR.
Ich zähle ja auch das selber hoch.