Dump bei SUSR_USER_BUFFERS_TO_DB
12 Beiträge
•
Seite 1 von 1
12 Beiträge
Seite 1 von 1
Hi @ all,
ich habe eine Frage zu oben genanntem FB.
In meiner Vorstellung möchte ich, dass die User in Zukunft automatisch mit dem Parameter PER und ihrer entsprechenden Personalnummer gefüllt werden. Ich habe die betroffenen Tabellen ausgelesen und versucht mit den Funktionsbausteinen SUSR_USER_PARAMETERS_PUT und SUSR_USER_BUFFERS_TO_DB den (teilweise) fehlenden Parameter den Usern hinzuzufügen.
Wenn ich das Programm im Debug Modus ausführe scheint nach dem Parameter SUSR_USER_PARAMETERS_PUT alles in Ordnung zu sein. Das Programm hat die User mit allen Parametern ausgelesen und bei einem User festgestellt, dass der Parameter PER fehlt. Dieser Satz wurde mit aufgenommen und soll nun via SUSR_USER_BUFFERS_TO_DB gesichert werden. Leider erhalte ich dann immer einen Dump, da der Datensatz mit der Parameter ID bereits vorhanden ist (trotz unterschiedlichem Wert).
Im nächsten Schritt habe ich versucht, dann nur den einzelnen Datensatz zu lesen, dem User zuzuordnen und zu speichern. Da habe ich dann das Problem, dass mir das Programm alle anderen IDs rausschmeißt und nur den neuen Parameter sichert.
Irgendwo habe ich einen Denkfehler oder mir fehlt Coding. Hat irgendjemand eine Idee was ich falsch mache oder vergessen habe? Oder hat vielleicht jemand eine Alternative? Ich habe auch schon ein wenig im WWW gesucht, aber dadurch habe ich mir das irgendwie einfacher vorgestellt.
Vielen lieben Dank vorab! Grüße K.Suta
ich habe eine Frage zu oben genanntem FB.
In meiner Vorstellung möchte ich, dass die User in Zukunft automatisch mit dem Parameter PER und ihrer entsprechenden Personalnummer gefüllt werden. Ich habe die betroffenen Tabellen ausgelesen und versucht mit den Funktionsbausteinen SUSR_USER_PARAMETERS_PUT und SUSR_USER_BUFFERS_TO_DB den (teilweise) fehlenden Parameter den Usern hinzuzufügen.
Wenn ich das Programm im Debug Modus ausführe scheint nach dem Parameter SUSR_USER_PARAMETERS_PUT alles in Ordnung zu sein. Das Programm hat die User mit allen Parametern ausgelesen und bei einem User festgestellt, dass der Parameter PER fehlt. Dieser Satz wurde mit aufgenommen und soll nun via SUSR_USER_BUFFERS_TO_DB gesichert werden. Leider erhalte ich dann immer einen Dump, da der Datensatz mit der Parameter ID bereits vorhanden ist (trotz unterschiedlichem Wert).
Im nächsten Schritt habe ich versucht, dann nur den einzelnen Datensatz zu lesen, dem User zuzuordnen und zu speichern. Da habe ich dann das Problem, dass mir das Programm alle anderen IDs rausschmeißt und nur den neuen Parameter sichert.
Irgendwo habe ich einen Denkfehler oder mir fehlt Coding. Hat irgendjemand eine Idee was ich falsch mache oder vergessen habe? Oder hat vielleicht jemand eine Alternative? Ich habe auch schon ein wenig im WWW gesucht, aber dadurch habe ich mir das irgendwie einfacher vorgestellt.
Vielen lieben Dank vorab! Grüße K.Suta
Code: Alles auswählen.
LOOP AT userp.
IF userp-gltgb < sy-datum.
* FREE lt_return. "wenn nur ein Datensatz übermittelt werden soll.
MOVE userp-parid to lt_return-parid.
MOVE userp-parva to lt_return-parva.
MOVE userp-bname to lt_return-partext. "zur Kontrolle
APPEND lt_return.
ELSE.
ENDIF.
ENDLOOP.
LOOP AT lt_return.
READ TABLE userp WITH KEY bname = lt_return-partext.
MOVE 'PER' to lt_return-parid.
MOVE userp-zpernr to lt_return-parva.
APPEND lt_return. "nun ein Datensatz mehr
CLEAR lt_return.
CALL FUNCTION 'SUSR_USER_PARAMETERS_PUT'
EXPORTING
USER_NAME = userp-bname
TABLES
USER_PARAMETERS = lt_return.
CALL FUNCTION 'SUSR_USER_BUFFERS_TO_DB'
EXCEPTIONS
NO_LOGONDATA_FOR_NEW_USER = 1
NO_INIT_PASSWORD = 2
DB_INSERT_USR02_FAILED = 3
DB_UPDATE_USR02_FAILED = 4
DB_INSERT_USR01_FAILED = 5
DB_UPDATE_USR01_FAILED = 6
DB_INSERT_USR05_FAILED = 7
DB_UPDATE_USR05_FAILED = 8
DB_INSERT_USR21_FAILED = 9
DB_UPDATE_USR21_FAILED = 10
INTERNAL_ERROR = 11
OTHERS = 12.
CLEAR lt_return.
ENDLOOP.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
413
)
»
Na ja, so wie ich Deinen Code lese, fügst Du der internen Tabelle lt_return erst alle schon vorhandenen Benutzerparameter hinzu (die Du vermutlich vorher irgendwie eingelesen hast). Dann fügst Du per APPEND noch den Parameter PER hinzu, ohne aber zu prüfen, ob er nicht schon bei den eingelesenen Parametern mit dabei war. Ggf. hast Du in Deiner Tabelle lt_return dann also den Parameter PER doppelt drin, was zu dem von Dir beschriebenen Fehlerbild passen würde. Das solltest Du also entsprechend vorher prüfen und in dem Fall auf ein MODIFY ausweichen.
Am Rande bemerkt: Ich finde es ja schön, dass hier auch jemand mal eine HCM-bezogene Frage stellt. Im Parameter PER steht ja normalerweise die Personalnummer drin, mit der man zuletzt gearbeitet hat (etwa in der PA30). Darf ich fragen, was Du damit bezweckst, den Benutzern ihre eigene Personalnummer in den Benutzerparametern vorzubelegen?
Am Rande bemerkt: Ich finde es ja schön, dass hier auch jemand mal eine HCM-bezogene Frage stellt. Im Parameter PER steht ja normalerweise die Personalnummer drin, mit der man zuletzt gearbeitet hat (etwa in der PA30). Darf ich fragen, was Du damit bezweckst, den Benutzern ihre eigene Personalnummer in den Benutzerparametern vorzubelegen?
Hi DeathAndPain,
erstmal vielen Dank für deine Antwort. Ja dass der Eintrag doppelt drin ist habe ich schon bemerkt, und auch schon geschrieben, dass mir das aufgefallen ist! Mein nächstes Problem war aber, dass wenn ich nur den "einzelnen" Satz einlese, dass der FB dann alle meine vorhandenen Parameter im User rauschmeißt und nur den PER Parameter einträgt. Vorschläge?
Bezüglich deiner Frage, muss ich etwas ausholen. Ich habe die Firma gewechselt und in der neuen Firma soll wenn möglich alles automatisiert ablaufen. Nun haben wir die Vorgabe, dass Mitarbeiter die via P30 die Maßnahme 10 (Austritt) erhalten, automatisch ein "Gültig bis" Datum im Userstamm verpasst bekommen. Da es aber Mitarbeiter gibt, die zwei Personalstämme haben (da noch ein Mini-Job dazu kam) oder welche ständig hin und her wechseln und dann auch andere Personalnummern erhalten und die nicht durchweg sauber gepflegt sind (zwei aktive Pers aber nur ein User), haben wir entschieden, die Personalnummer automatisch im Benutzerstamm zu hinterlegen, damit wir eine eindeutige Zuordnung haben. In meiner alten Firma haben wir im aktiven Personalstamm die User ID hinterlegt (also entgegengesetzter Weg). Ich versuche mal die Logik anzupassen, vielleicht finde ich einen anderen Weg. Vielen Dank dennoch!
erstmal vielen Dank für deine Antwort. Ja dass der Eintrag doppelt drin ist habe ich schon bemerkt, und auch schon geschrieben, dass mir das aufgefallen ist! Mein nächstes Problem war aber, dass wenn ich nur den "einzelnen" Satz einlese, dass der FB dann alle meine vorhandenen Parameter im User rauschmeißt und nur den PER Parameter einträgt. Vorschläge?
Bezüglich deiner Frage, muss ich etwas ausholen. Ich habe die Firma gewechselt und in der neuen Firma soll wenn möglich alles automatisiert ablaufen. Nun haben wir die Vorgabe, dass Mitarbeiter die via P30 die Maßnahme 10 (Austritt) erhalten, automatisch ein "Gültig bis" Datum im Userstamm verpasst bekommen. Da es aber Mitarbeiter gibt, die zwei Personalstämme haben (da noch ein Mini-Job dazu kam) oder welche ständig hin und her wechseln und dann auch andere Personalnummern erhalten und die nicht durchweg sauber gepflegt sind (zwei aktive Pers aber nur ein User), haben wir entschieden, die Personalnummer automatisch im Benutzerstamm zu hinterlegen, damit wir eine eindeutige Zuordnung haben. In meiner alten Firma haben wir im aktiven Personalstamm die User ID hinterlegt (also entgegengesetzter Weg). Ich versuche mal die Logik anzupassen, vielleicht finde ich einen anderen Weg. Vielen Dank dennoch!
huhu,
Wenn du an den Fuba nur einen Parameter übergibst, überschreibt dieser die Parameter, daher steht dann auch nur der eine Parameter drin den du übergeben hast.
Liebe Grüße
abuma
Ich nehme mal an man muss vorher immer erst die bereits vorhandenen Parameter einlesen, den neuen Parameter dazu nehmen und dann den Fuba-Aufruf mit allen Parametern machen. Den alten sowie den dazugekommenen.Suta_K hat geschrieben:Mein nächstes Problem war aber, dass wenn ich nur den "einzelnen" Satz einlese, dass der FB dann alle meine vorhandenen Parameter im User rauschmeißt und nur den PER Parameter einträgt. Vorschläge?
Wenn du an den Fuba nur einen Parameter übergibst, überschreibt dieser die Parameter, daher steht dann auch nur der eine Parameter drin den du übergeben hast.
Liebe Grüße
abuma
Hi abuma,
ja soweit klar. Ich loope aber über die komplette itab, wo auch User drin stehen, die vermutlich bereits den Parameter im Userstamm haben, und dann kommt das duplicate error. Ich denke ich habe da einen Fehler im Coding drin.
ja soweit klar. Ich loope aber über die komplette itab, wo auch User drin stehen, die vermutlich bereits den Parameter im Userstamm haben, und dann kommt das duplicate error. Ich denke ich habe da einen Fehler im Coding drin.
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
413
)
»
Hab mir Deinen Code nochmal genauer angeschaut. Du machst APPENDs an die lt_return innerhalb eines LOOPS über die lt_return?! Das scheint mir so keinen Sinn zu machen. Der erste LOOP über die USERP ist in Ordnung. Damit kopierst Du alle bestehenden Parameter des Users in die lt_return, damit bei der ganzen Aktion keine davon verlorengehen (so wie Du es jetzt gerade beobachtest). Aber den zweiten LOOP kannste Dir komplett sparen.
Und vor allem: Du übergibst die ganze Tabelle lt_return an den Funktionsbaustein SUSR_USER_PARAMETERS_PUT, während Du einen LOOP darüber machst (also so oft, wie die Tabelle Einträge hat)?!? Das macht ja nun gar keinen Sinn.
Ohne meinen Code tatsächlich getestet zu haben, würde ich sagen, dass es so gehen müsste:
Unklar ist mir aber auch, wie der Inhalt Deiner internen Tabelle USERP zustande kommt. Die sieht so aus, als ob da einfach alle alten Benutzerparameter reingelesen worden wären und dann irgendwie die Personalnummer dazugemixt worden wäre. Das wäre natürlich die nächste Falle: Hat ein User bisher noch gar keinen Parameter, dann ist er in der Tabelle gar nicht dabei und wird daher auch keinen neuen PER bekommen.
Ggf. könnte man den obenstehenden Code noch etwas vereinfachen, indem man einfach vorher mit einem DELETE WHERE alle alten PER aus der USERP rausschmeißt. Dann hätte man auf keinen Fall mehr doppelte Einträge. Vor allem aber würde ich in der Definition von USERP möglichst das Feld BNAME an den Anfang stellen, damit ich im LOOP mit AT END OF arbeiten kann.
Und vor allem: Du übergibst die ganze Tabelle lt_return an den Funktionsbaustein SUSR_USER_PARAMETERS_PUT, während Du einen LOOP darüber machst (also so oft, wie die Tabelle Einträge hat)?!? Das macht ja nun gar keinen Sinn.
Ohne meinen Code tatsächlich getestet zu haben, würde ich sagen, dass es so gehen müsste:
Code: Alles auswählen.
REPORT ZTEST4.
DATA: BEGIN OF USERP OCCURS 0,
ZPERNR TYPE PERSNO,
GLTGB TYPE ENDDA,
BNAME TYPE UNAME,
PARID TYPE MEMORYID,
PARVA TYPE XUVALUE,
PARTEXT TYPE AS4TEXT,
END OF USERP,
LT_RETURN TYPE USTYP_T_PARAMETERS WITH HEADER LINE,
PER_IST_VORHANDEN TYPE C,
NAECHSTER_EINTRAG LIKE USERP,
ANZAHL_ZEILEN_IN_USERP TYPE I.
START-OF-SELECTION.
SORT USERP BY BNAME. " wichtig, sonst klappt mein simulierter AT END OF nicht
DESCRIBE TABLE USERP LINES ANZAHL_ZEILEN_IN_USERP.
LOOP AT USERP.
IF USERP-GLTGB < SY-DATUM.
MOVE USERP-PARID TO LT_RETURN-PARID.
MOVE USERP-BNAME TO LT_RETURN-PARTEXT. "zur Kontrolle
CASE USERP-PARID.
WHEN 'PER'.
MOVE USERP-ZPERNR TO LT_RETURN-PARVA.
PER_IST_VORHANDEN = 'X'.
WHEN OTHERS.
MOVE USERP-PARVA TO LT_RETURN-PARVA.
ENDCASE.
APPEND LT_RETURN.
* AT END OF simulieren, da ich nicht weiß, ob BNAME das erste Feld in USERP ist (nächstes Mal bitte kompletten Code oder zumindest die Typisierungen angeben!)
* Ab Release 7.40 wäre auch ein LOOP AT ... GROUP BY denkbar
IF SY-TABIX < ANZAHL_ZEILEN_IN_USERP. " oder LINES() verwenden, wenn Releasestand ausreichend hoch
READ TABLE USERP INTO NAECHSTER_EINTRAG INDEX SY-TABIX + 1.
ELSE.
CLEAR NAECHSTER_EINTRAG. " dann ist der folgende IF immer wahr
ENDIF.
IF NAECHSTER_EINTRAG-BNAME <> USERP-BNAME. " wenn aktuelle LOOP-Zeile letzten Parameter dieses Users enthält (deswegen oben der SORT vor dem LOOP)
IF PER_IST_VORHANDEN IS INITIAL. " war für diesen User ein alter Parameter PER dabei?
* Parameter PER hinzufügen, wenn er bisher noch nicht da war
MOVE 'PER' TO LT_RETURN-PARID.
MOVE USERP-ZPERNR TO LT_RETURN-PARVA.
APPEND LT_RETURN.
ENDIF.
CALL FUNCTION 'SUSR_USER_PARAMETERS_PUT'
EXPORTING USER_NAME = USERP-BNAME
TABLES USER_PARAMETERS = LT_RETURN.
CLEAR PER_IST_VORHANDEN. " leermachen für nächste Userkennung
REFRESH LT_RETURN.
ENDIF.
ENDIF.
ENDLOOP.
CALL FUNCTION 'SUSR_USER_BUFFERS_TO_DB'
EXCEPTIONS
NO_LOGONDATA_FOR_NEW_USER = 1
NO_INIT_PASSWORD = 2
DB_INSERT_USR02_FAILED = 3
DB_UPDATE_USR02_FAILED = 4
DB_INSERT_USR01_FAILED = 5
DB_UPDATE_USR01_FAILED = 6
DB_INSERT_USR05_FAILED = 7
DB_UPDATE_USR05_FAILED = 8
DB_INSERT_USR21_FAILED = 9
DB_UPDATE_USR21_FAILED = 10
INTERNAL_ERROR = 11
OTHERS = 12.Ggf. könnte man den obenstehenden Code noch etwas vereinfachen, indem man einfach vorher mit einem DELETE WHERE alle alten PER aus der USERP rausschmeißt. Dann hätte man auf keinen Fall mehr doppelte Einträge. Vor allem aber würde ich in der Definition von USERP möglichst das Feld BNAME an den Anfang stellen, damit ich im LOOP mit AT END OF arbeiten kann.
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
413
)
»
So ist es auch der richtige Weg. Die Userkennung gehört in den Infotyp 105 Subtyp 0001 der Personalnummer. Dort erwartet SAP sie auch, und dann hast Du auch beide Richtung effizient im Suchzugriff (da die PA0105 einen Sekundärindex auf USRTY/USRID hat, kannst Du mit USRTY = '0001', USRID = Benutzername effizient die Personalnummer suchen).In meiner alten Firma haben wir im aktiven Personalstamm die User ID hinterlegt (also entgegengesetzter Weg).
Alles andere halte ich, wenn mir die Deutlichkeit gestattet ist, für Pfusch. Der Parameter PER ist für Personalsachbearbeiter gedacht. Wenn man denen ihre Personalnummer da reinpackt, dann kriegen die sich immer erst mal selber vorgeblendet, wenn sie morgens mit der Arbeit anfangen. Ich wüsste auch sonst keinen Grund, die Userkennung woanders zu hinterlegen als im IT 105. Das wird vom SAP-Standard auch noch für andere Zwecke genutzt. Beispielsweise kannst Du im Berechtigungsobjekt P_PERNR hinterlegen, dass niemand seine eigenen Gehaltsdaten pflegen darf, auch wenn er ansonsten gehaltspflegeberechtigt ist (--> Personalsachbearbeiter) oder dass Mitarbeiter ihre eigene Anschrift pflegen dürfen (etwa über ESS). Um herauszufinden, welche Personalnummer eine Userkennung hat, verwendet SAP bei dem Berechtigungsobjekt P_PERNR implizit den Infotyp 105.
Das ist also ganz eindeutig die einzig richtige Stelle, um die Verbindung Benutzerkennung <-> Personalnummer zu pflegen.
Hi DeathAndPain,
vielen vielen DANK!! Ich werde mir heute dein Coding genauer anschauen. Das Loopen macht echt keinen Sinn
Das persönliche Problem was ich habe ist, dass ich mich in meiner alten Firma mehr um Organisation und Basis Betreuung gekümmert und selten programmiert.
Jetzt muss ich mich erst mal wieder eingrooven ins Programmieren.
Ich werde dir dann noch eine Rückmeldung geben, ob es geklappt hat!
Bezüglich SAP User in PerNr => Werde ich hier auch wieder einführen. Vielen Dank für die Zustimmung!
vielen vielen DANK!! Ich werde mir heute dein Coding genauer anschauen. Das Loopen macht echt keinen Sinn
Das persönliche Problem was ich habe ist, dass ich mich in meiner alten Firma mehr um Organisation und Basis Betreuung gekümmert und selten programmiert.
Jetzt muss ich mich erst mal wieder eingrooven ins Programmieren.
Ich werde dir dann noch eine Rückmeldung geben, ob es geklappt hat!
Bezüglich SAP User in PerNr => Werde ich hier auch wieder einführen. Vielen Dank für die Zustimmung!
Hi DeathAndPain,
habe das Coding jetzt mal eingebaut und mit drei Usern getestet.
User 1 = BU, 10 Parameter, ParID PER vorhanden, sy-tabix zählt normal hoch, bei sy-tabix 11 naechster_eintrag-bname = KA => User BU wird angepasst mit FuBu 'SUSR_USER_PARAMETERS_PUT'
User 2 = KA, 6 Parameter, ParID PER nicht vorhanden, sy-tabix fängt bei 1 an (nach APPEND LT_RETURN), tab "naechster_eintrag" fängt wieder bei User BU an => User KA rutscht nun jedes mal in das Update => alte Parameter werden mit ParID PER überklatscht.
User 3 = WI, 1 Parameter, ParID PER vorhanden, sy-tabix fängt bei 1 an (nach APPEND LT_RETURN), tab "naechster_eintrag" fängt wieder bei User BU an => Update => Programm beendet.
Kurze Randinfo: Die userp befüllen wir mit einer Tabelle, die aus einem anderen Programm generiert wird, wenn z.B. ein MA eine neue Maßnahme durch HR erhält (Eintritt, Austritt, usw.), dort gibt es aber auch noch keine User Verknüpfung (da ja nicht jeder MA einen SAP User hat). Trotz dessen, dass wir hier die Methode aus meiner alten Firma (User in PerNr) übernehmen, würde mich dennoch interessieren, warum der sy-tabix nach einem erfolgreichen Lauf beim 1. User, dann bei allen Folgeuser immer bei 1 anfängt.
Vielen Dank nochmal für deine schnelle Hilfe/Idee/Inspiration
LG K.Suta
habe das Coding jetzt mal eingebaut und mit drei Usern getestet.
User 1 = BU, 10 Parameter, ParID PER vorhanden, sy-tabix zählt normal hoch, bei sy-tabix 11 naechster_eintrag-bname = KA => User BU wird angepasst mit FuBu 'SUSR_USER_PARAMETERS_PUT'
User 2 = KA, 6 Parameter, ParID PER nicht vorhanden, sy-tabix fängt bei 1 an (nach APPEND LT_RETURN), tab "naechster_eintrag" fängt wieder bei User BU an => User KA rutscht nun jedes mal in das Update => alte Parameter werden mit ParID PER überklatscht.
User 3 = WI, 1 Parameter, ParID PER vorhanden, sy-tabix fängt bei 1 an (nach APPEND LT_RETURN), tab "naechster_eintrag" fängt wieder bei User BU an => Update => Programm beendet.
Kurze Randinfo: Die userp befüllen wir mit einer Tabelle, die aus einem anderen Programm generiert wird, wenn z.B. ein MA eine neue Maßnahme durch HR erhält (Eintritt, Austritt, usw.), dort gibt es aber auch noch keine User Verknüpfung (da ja nicht jeder MA einen SAP User hat). Trotz dessen, dass wir hier die Methode aus meiner alten Firma (User in PerNr) übernehmen, würde mich dennoch interessieren, warum der sy-tabix nach einem erfolgreichen Lauf beim 1. User, dann bei allen Folgeuser immer bei 1 anfängt.
Vielen Dank nochmal für deine schnelle Hilfe/Idee/Inspiration
LG K.Suta
Moin.
Soweit ich verstanden habe, soll ein Benutzer-Parameter eingefügt bzw. geändert werden.
Für diesen Zweck würde ich den Baustein BAPI_USER_CHANGE verwenden.
Siehe Bausteinbeschreibung.
gruß Jens
Soweit ich verstanden habe, soll ein Benutzer-Parameter eingefügt bzw. geändert werden.
Für diesen Zweck würde ich den Baustein BAPI_USER_CHANGE verwenden.
Siehe Bausteinbeschreibung.
gruß Jens
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
413
)
»
Kleiner Bug in meinem Coding. SY-TABIX wird vom LOOP gesetzt, vom APPEND jedoch auch (bzgl. der Tabelle LT_RETURN), so dass wir dann die Zeilennummer aus der falschen Tabelle in SY-TABIX zu stehen haben. Diesen Umstand habe ich übersehen; wie gesagt, ich hatte mein Coding nicht getestet.Trotz dessen, dass wir hier die Methode aus meiner alten Firma (User in PerNr) übernehmen, würde mich dennoch interessieren, warum der sy-tabix nach einem erfolgreichen Lauf beim 1. User, dann bei allen Folgeuser immer bei 1 anfängt.
Das lässt sich aber leicht umschiffen, indem wir uns den richtigen SY-TABIX aus dem LOOP merken und damit weiterarbeiten. Hier das neue Coding:
Code: Alles auswählen.
REPORT ZTEST4.
DATA: BEGIN OF USERP OCCURS 0,
ZPERNR TYPE PERSNO,
GLTGB TYPE ENDDA,
BNAME TYPE UNAME,
PARID TYPE MEMORYID,
PARVA TYPE XUVALUE,
PARTEXT TYPE AS4TEXT,
END OF USERP,
LT_RETURN TYPE USTYP_T_PARAMETERS WITH HEADER LINE,
PER_IST_VORHANDEN TYPE C,
NAECHSTER_EINTRAG LIKE USERP,
ANZAHL_ZEILEN_IN_USERP TYPE I,
TABIX_MERKER LIKE SY-TABIX.
START-OF-SELECTION.
SORT USERP BY BNAME. " wichtig, sonst klappt mein simulierter AT END OF nicht
DESCRIBE TABLE USERP LINES ANZAHL_ZEILEN_IN_USERP.
LOOP AT USERP.
TABIX_MERKER = SY-TABIX.
IF USERP-GLTGB < SY-DATUM.
MOVE USERP-PARID TO LT_RETURN-PARID.
MOVE USERP-BNAME TO LT_RETURN-PARTEXT. "zur Kontrolle
CASE USERP-PARID.
WHEN 'PER'.
MOVE USERP-ZPERNR TO LT_RETURN-PARVA.
PER_IST_VORHANDEN = 'X'.
WHEN OTHERS.
MOVE USERP-PARVA TO LT_RETURN-PARVA.
ENDCASE.
APPEND LT_RETURN.
* AT END OF simulieren, da ich nicht weiß, ob BNAME das erste Feld in USERP ist (nächstes Mal bitte kompletten Code oder zumindest die Typisierungen angeben!)
* Ab Release 7.40 wäre auch ein LOOP AT ... GROUP BY denkbar
IF TABIX_MERKER < ANZAHL_ZEILEN_IN_USERP. " oder LINES() verwenden, wenn Releasestand ausreichend hoch
READ TABLE USERP INTO NAECHSTER_EINTRAG INDEX TABIX_MERKER + 1.
ELSE.
CLEAR NAECHSTER_EINTRAG. " dann ist der folgende IF immer wahr
ENDIF.
IF NAECHSTER_EINTRAG-BNAME <> USERP-BNAME. " wenn aktuelle LOOP-Zeile letzten Parameter dieses Users enthält (deswegen oben der SORT vor dem LOOP)
IF PER_IST_VORHANDEN IS INITIAL. " war für diesen User ein alter Parameter PER dabei?
* Parameter PER hinzufügen, wenn er bisher noch nicht da war
MOVE 'PER' TO LT_RETURN-PARID.
MOVE USERP-ZPERNR TO LT_RETURN-PARVA.
APPEND LT_RETURN.
ENDIF.
CALL FUNCTION 'SUSR_USER_PARAMETERS_PUT'
EXPORTING USER_NAME = USERP-BNAME
TABLES USER_PARAMETERS = LT_RETURN.
CLEAR PER_IST_VORHANDEN. " leermachen für nächste Userkennung
ENDIF.
ENDIF.
ENDLOOP.
CALL FUNCTION 'SUSR_USER_BUFFERS_TO_DB'
EXCEPTIONS
NO_LOGONDATA_FOR_NEW_USER = 1
NO_INIT_PASSWORD = 2
DB_INSERT_USR02_FAILED = 3
DB_UPDATE_USR02_FAILED = 4
DB_INSERT_USR01_FAILED = 5
DB_UPDATE_USR01_FAILED = 6
DB_INSERT_USR05_FAILED = 7
DB_UPDATE_USR05_FAILED = 8
DB_INSERT_USR21_FAILED = 9
DB_UPDATE_USR21_FAILED = 10
INTERNAL_ERROR = 11
OTHERS = 12.Hi DeathAndPain,
entschuldige, dass ich so spät antworte (war krank).
Also habe das Coding für den sy-tabix übernommen. Jetzt zählt das Programm zwar richtig hoch, aber ich bekomme wieder den Dump SAPSQL_ARRAY_INSERT_DUPREC, sobald der FuBa SUSR_USER_BUFFERS_TO_DB angesteuert wird. In der Tabelle sind zwei Einträge mit PER (weil ich mit 2 Usern getestet habe).
Danke trotzdem für deine Bemühungen...
LG K.Suta
entschuldige, dass ich so spät antworte (war krank).
Also habe das Coding für den sy-tabix übernommen. Jetzt zählt das Programm zwar richtig hoch, aber ich bekomme wieder den Dump SAPSQL_ARRAY_INSERT_DUPREC, sobald der FuBa SUSR_USER_BUFFERS_TO_DB angesteuert wird. In der Tabelle sind zwei Einträge mit PER (weil ich mit 2 Usern getestet habe).
Danke trotzdem für deine Bemühungen...
LG K.Suta
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
6019
Views
Views
2
Antw.
Antw.
1841
Views
Views
1
Antw.
Antw.
2408
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1168
vor 2 Tagen von DeathAndPain 4 / 1168
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1168
vor 2 Tagen von DeathAndPain 4 / 1168