@-Zeichen im RFC-Funktionsbaustein
Hallo Jens,
vielen Dank, das hat viel geholfen.
Ich konnte die Aufrufe nun mit meinem eigenen SAP-User debuggen.
Die Umschlüsselung 2@ bzw 3@ auf @@ / @@@ funktionert jetzt. Grund war eindeutig, dass die Verbindung zwischen Remote System und SAP nicht durchgestartet wurde und noch das alte Coding gelesen wurde. Damit ist Punkt 2 aus meiner Liste oben erledigt.
Es bleiben noch Punkt 3 (Texte fortschreiben) bzw. Punkt 1 (warum kann @@ und @@@ nicht übernommen werden, warum ist eine Umschlüsselung - die nun funktioniert - erforderlich?)
Zu Punkt 3 - Texte.
In dem Fall, wo man die Tabellenparameter im RFC-System erst gar nicht versorgt hat, aber es wurden trotzdem Texte empfangen (und auch im SAP fortgeschrieben), lag das Problem irgendwie an der Initialisierung der Tabellenparameter. Zuerst ruft man den Baustein im Lesemodus. Dann werden blestehende Texte in diese Tabellenparameter eingestellt und zurückgegeben. Dann ruft das RFC-System den selben Baustein im Update-Modus auf, übergibt seinerseits nichts in der Tabelle, es kommt jedoch der gerade gelesene Inhalt zurück. "Neue" Texte müssen hier einfach hinten angehängt werden, damit werden also die Texte im SAP verdoppelt. Beim nächsten Lese-Schreibe-Zyklus findet wieder eine Verdoppelung statt, etc. Wenn man im RFC-System die Tabellenparameter explizit initialisiert, dann werden auch keine Texte fortgeschrieben. *freu*
In dem anderen Fall jedoch, das ist auch irgendwie Java-basiert, will man Texte fortschreiben, man versorgt (angeblich) den Tabellenparameter mit 2 Zeilen, im Baustein beim Debugging ist die Tabelle allerdings immer leer, es kommt nichts an, und damit werden auch keine Texte fortgeschrieben. Die Texte sind irgendwie "verschluckt". Die Tabelle (DDIC-Struktur TLINE) hat ja zwei Felder, TDFORMAT und TDLINE. TDFORMAT wird i.d.R. mit einem Stern (*) übergeben, jetzt haben wir auch blank und 1* versucht, kein Ergebnis. (in TDLINE steht halt die eigentlichee Textzeile).
Zu Punkt 1 - @@
Das ist durch Punkt 2 eigentlich vom Tisch, weil ja die Umschlüsselung funktioniert. Ich würde gerne nochmal darauf zurückkommen, wenn die Texte (Punkt 3) erledigt sind. Hier nochmal das Symptom: kommt für ein CHAR3 Feld @@ oder @@@ an, wird ein Abbruch an das rufende RFC-System zurückgegeben. im SAP gibt es kein Kurzdump, der Prozess wird wahrscheinlich noch bevor SAP erreicht wird, abgebrochen. Mit nur einem @ funktioniert der Aufruf, das eine @ Zeichen kann auch im SAP fortgeschrieben werden.
Grüße,
scsaba
vielen Dank, das hat viel geholfen.
Ich konnte die Aufrufe nun mit meinem eigenen SAP-User debuggen.
Die Umschlüsselung 2@ bzw 3@ auf @@ / @@@ funktionert jetzt. Grund war eindeutig, dass die Verbindung zwischen Remote System und SAP nicht durchgestartet wurde und noch das alte Coding gelesen wurde. Damit ist Punkt 2 aus meiner Liste oben erledigt.
Es bleiben noch Punkt 3 (Texte fortschreiben) bzw. Punkt 1 (warum kann @@ und @@@ nicht übernommen werden, warum ist eine Umschlüsselung - die nun funktioniert - erforderlich?)
Zu Punkt 3 - Texte.
In dem Fall, wo man die Tabellenparameter im RFC-System erst gar nicht versorgt hat, aber es wurden trotzdem Texte empfangen (und auch im SAP fortgeschrieben), lag das Problem irgendwie an der Initialisierung der Tabellenparameter. Zuerst ruft man den Baustein im Lesemodus. Dann werden blestehende Texte in diese Tabellenparameter eingestellt und zurückgegeben. Dann ruft das RFC-System den selben Baustein im Update-Modus auf, übergibt seinerseits nichts in der Tabelle, es kommt jedoch der gerade gelesene Inhalt zurück. "Neue" Texte müssen hier einfach hinten angehängt werden, damit werden also die Texte im SAP verdoppelt. Beim nächsten Lese-Schreibe-Zyklus findet wieder eine Verdoppelung statt, etc. Wenn man im RFC-System die Tabellenparameter explizit initialisiert, dann werden auch keine Texte fortgeschrieben. *freu*
In dem anderen Fall jedoch, das ist auch irgendwie Java-basiert, will man Texte fortschreiben, man versorgt (angeblich) den Tabellenparameter mit 2 Zeilen, im Baustein beim Debugging ist die Tabelle allerdings immer leer, es kommt nichts an, und damit werden auch keine Texte fortgeschrieben. Die Texte sind irgendwie "verschluckt". Die Tabelle (DDIC-Struktur TLINE) hat ja zwei Felder, TDFORMAT und TDLINE. TDFORMAT wird i.d.R. mit einem Stern (*) übergeben, jetzt haben wir auch blank und 1* versucht, kein Ergebnis. (in TDLINE steht halt die eigentlichee Textzeile).
Zu Punkt 1 - @@
Das ist durch Punkt 2 eigentlich vom Tisch, weil ja die Umschlüsselung funktioniert. Ich würde gerne nochmal darauf zurückkommen, wenn die Texte (Punkt 3) erledigt sind. Hier nochmal das Symptom: kommt für ein CHAR3 Feld @@ oder @@@ an, wird ein Abbruch an das rufende RFC-System zurückgegeben. im SAP gibt es kein Kurzdump, der Prozess wird wahrscheinlich noch bevor SAP erreicht wird, abgebrochen. Mit nur einem @ funktioniert der Aufruf, das eine @ Zeichen kann auch im SAP fortgeschrieben werden.
Grüße,
scsaba
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hallo zusammen,
Punkt 3 - Texte hat sich auch geklärt.
Obwohl die Behauptung war dass der Tabellenparameter im RFC-System versorgt wurde, hat man höchstens den Kopfsatz befüllt. Daher kam die Tabelle immer leer an. Man grübelt jetzt gerade wie man nun eine Tabelle füllen kann
Auf jeden Fall hat sich das Problem aus SAP-Sicht gelöst.
Fazit bisher:
a) Inhalt der Tabellenparameter wird unterwegs nicht initialisert. Will man die Tabelle leer ans SAP System übergeben, muss man sie komplett initialisieren (Punkt 2).
b) Tabellenparameter müssen oredntlich befüllt werden im RFC-System (Punkt 3)
Es bleibt noch das ursprünglich Problem (Punkt 1) stehen: @@ und @@@ führen zu einem Timeout auf RFC-Seite. @ (ein @) geht problemlos durch. Als Workaroud wird jetzt umgeschlüsselt (2@ auf @@, 3@ auf @@@), das ist aber unschön...
Danke für die Hinweise, ich hoffe ich kann bald die Lösung für Punkt 1 hier einstellen...
Grüße,
scsaba
Punkt 3 - Texte hat sich auch geklärt.
Obwohl die Behauptung war dass der Tabellenparameter im RFC-System versorgt wurde, hat man höchstens den Kopfsatz befüllt. Daher kam die Tabelle immer leer an. Man grübelt jetzt gerade wie man nun eine Tabelle füllen kann
Auf jeden Fall hat sich das Problem aus SAP-Sicht gelöst.Fazit bisher:
a) Inhalt der Tabellenparameter wird unterwegs nicht initialisert. Will man die Tabelle leer ans SAP System übergeben, muss man sie komplett initialisieren (Punkt 2).
b) Tabellenparameter müssen oredntlich befüllt werden im RFC-System (Punkt 3)
Es bleibt noch das ursprünglich Problem (Punkt 1) stehen: @@ und @@@ führen zu einem Timeout auf RFC-Seite. @ (ein @) geht problemlos durch. Als Workaroud wird jetzt umgeschlüsselt (2@ auf @@, 3@ auf @@@), das ist aber unschön...
Danke für die Hinweise, ich hoffe ich kann bald die Lösung für Punkt 1 hier einstellen...
Grüße,
scsaba
Moin,
schau doch vielleicht mal nach, ob das übergebe @ Zeichen aus einem, oder 2 Byte besteht (also Unicode). Dann wären @@ ja 4 CHAR-Zeichen und damit ein Abbruch Erklärbär.
Man kann das im Debugging sehen, wenn man auf die "Lupe" neben der Variablen clickt.
gruß Jens
schau doch vielleicht mal nach, ob das übergebe @ Zeichen aus einem, oder 2 Byte besteht (also Unicode). Dann wären @@ ja 4 CHAR-Zeichen und damit ein Abbruch Erklärbär.
Man kann das im Debugging sehen, wenn man auf die "Lupe" neben der Variablen clickt.
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.
Hallo Jens,
eine traurige Nachricht zum Abschluss: wir konnten nicht herausfinden, woran es schließlich lag, es bleibt bei der Umschlüsselung.
Die Idee mit Multibyte hat mir sehr gefallen, aber die Leute konnten aus Zeitgründen keine weiteren Tests mehr machen (ich habe Sie gebeten, für einen CHAR8 Feld mal @@ zu übergeben, das hätte ja von der Länge her passen können). Allerdings haben Sie mir gemeldet, dass in einem CHAR50 Feld, wo der Inhalt doch deutlich unter der max.Länge war, die Zeichnfolge @@ auch zurückgewiesen wurde, und zwar mit dem selben Fehler (timeout). Ich konnte diesen Fall gar nicht debuggen, weil der Prozess abgebrochen wurde noch bevor unser RFC-Baustein aufgerufen war. Also es wurde die Umschlüsselung generell eingebaut (nicht nur für das eine CHAR3 Feld, sondern grundsätzlich für alle Felder, und 2@ und 3@ brauchen nicht der gesamte Inhalt zu sein, diese Zeichenfolgen können auch irgendwo zwischen drin stehen.) So funktioniert das OK, und die Leute freuen sich, und die wollen auch nicht unbedingt verstehen warum das so ist
Nochmal die Zusammenfassung:
1.
Zeichenfolgen wie @@ und @@@ verursachen einen bis jetzt unbekannten Fehler der irgendwo bei der Überleitung vom RFC-System ins SAP System auftaucht. Im SAP kann man den Fehler nicht sehen. Eine Erklärung wurde nicht gefunden, stattdessen wurde eine Umschlüsselung eingebaut (2@ wiord im SAP auf @@, 3@ auf @@@ umgeschlüsselt).
2.
Tabellenparameter werden, wenn Sie bei einem lesenden Zugriff im RFC-.Baustein befüllt werden, beim sofort darauffolgenden Schreibenden Zugriff nicht automatisch initialisiert. Wenn im RFC-System die Tabelle nicht explizit initialisiert wird, kommt der gerade gelesene Inhalt zurück. (AUfgabe der beiden AUfrufe: erst Kundenstamm lesen, dann im RFC-Syytem entscheiden ob etwas geändert werden soll, wenn ja, dann den selben RFC-Baustein im Schreibemodus rufen).
3.
Tabellenparameter müssen im RFC-System richtig versorgt werden, insbesondere reicht es nicht aus, nur den Kopfsatz zu befüllen (auch nicht wenn man grundsätzlich immer nur eine Zeile in die Tabelle einstellen möchte). Der Kopfsatz wird ja nie übergeben, die Tabelle kommt leer an. (Weil es immer nur eine "Zeile" ist. hätte man auch mit einer flachen Struktur arbeiten können, aber der lesende Zugriff - s.oben - kann durchaus mehrere Zeilen zurückliefern, dann reicht eine Struktuer nicht aus.)
Vielen Dank nochmals an Euch für die guten Hinweise
Schöne Grüße,
scsaba
eine traurige Nachricht zum Abschluss: wir konnten nicht herausfinden, woran es schließlich lag, es bleibt bei der Umschlüsselung.
Die Idee mit Multibyte hat mir sehr gefallen, aber die Leute konnten aus Zeitgründen keine weiteren Tests mehr machen (ich habe Sie gebeten, für einen CHAR8 Feld mal @@ zu übergeben, das hätte ja von der Länge her passen können). Allerdings haben Sie mir gemeldet, dass in einem CHAR50 Feld, wo der Inhalt doch deutlich unter der max.Länge war, die Zeichnfolge @@ auch zurückgewiesen wurde, und zwar mit dem selben Fehler (timeout). Ich konnte diesen Fall gar nicht debuggen, weil der Prozess abgebrochen wurde noch bevor unser RFC-Baustein aufgerufen war. Also es wurde die Umschlüsselung generell eingebaut (nicht nur für das eine CHAR3 Feld, sondern grundsätzlich für alle Felder, und 2@ und 3@ brauchen nicht der gesamte Inhalt zu sein, diese Zeichenfolgen können auch irgendwo zwischen drin stehen.) So funktioniert das OK, und die Leute freuen sich, und die wollen auch nicht unbedingt verstehen warum das so ist
Nochmal die Zusammenfassung:
1.
Zeichenfolgen wie @@ und @@@ verursachen einen bis jetzt unbekannten Fehler der irgendwo bei der Überleitung vom RFC-System ins SAP System auftaucht. Im SAP kann man den Fehler nicht sehen. Eine Erklärung wurde nicht gefunden, stattdessen wurde eine Umschlüsselung eingebaut (2@ wiord im SAP auf @@, 3@ auf @@@ umgeschlüsselt).
2.
Tabellenparameter werden, wenn Sie bei einem lesenden Zugriff im RFC-.Baustein befüllt werden, beim sofort darauffolgenden Schreibenden Zugriff nicht automatisch initialisiert. Wenn im RFC-System die Tabelle nicht explizit initialisiert wird, kommt der gerade gelesene Inhalt zurück. (AUfgabe der beiden AUfrufe: erst Kundenstamm lesen, dann im RFC-Syytem entscheiden ob etwas geändert werden soll, wenn ja, dann den selben RFC-Baustein im Schreibemodus rufen).
3.
Tabellenparameter müssen im RFC-System richtig versorgt werden, insbesondere reicht es nicht aus, nur den Kopfsatz zu befüllen (auch nicht wenn man grundsätzlich immer nur eine Zeile in die Tabelle einstellen möchte). Der Kopfsatz wird ja nie übergeben, die Tabelle kommt leer an. (Weil es immer nur eine "Zeile" ist. hätte man auch mit einer flachen Struktur arbeiten können, aber der lesende Zugriff - s.oben - kann durchaus mehrere Zeilen zurückliefern, dann reicht eine Struktuer nicht aus.)
Vielen Dank nochmals an Euch für die guten Hinweise
Schöne Grüße,
scsaba
Moin scsaba,
Bei uns lag es am SAPGUI 720 . Ein Downgrade auf 710 brachte den gewünschten Erfolg !
gruß Jens
Ich habe jetzt die Aufgabe, das Phänomen genauer zu untersuchen
(oder hast Du geglaubt, daß Du aus Dieser Nummer raus bist ? )
Wir haben jetzt ein ähnliches bzw. das gleiche Problem !eine traurige Nachricht zum Abschluss: wir konnten nicht herausfinden, woran es schließlich lag,....
Bei uns lag es am SAPGUI 720 . Ein Downgrade auf 710 brachte den gewünschten Erfolg !
gruß Jens
Ich habe jetzt die Aufgabe, das Phänomen genauer zu untersuchen
(oder hast Du geglaubt, daß Du aus Dieser Nummer raus bist ?
)
<:: 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.
[quote="Tron"]Moin scsaba,
[size=85](oder hast Du geglaubt, daß Du aus Dieser Nummer raus bist ? )[/size][/quote]
Hallo Jens,
zugegeben, das war mein erster Gedanke...
Aber wie man sieht, ich bin doch zurückgekommen weil ich gedanklich nicht darüber hinwegkommen kann...
Du sagst es liegt an der SAPGUI-Version - entschuldige die blöde Frage aber wie kommt das SAPGUI hier erst ins Spiel? Der extrene System ruft unseren RFC-Funktionsbaustein. Die Verbindung legt fest, unter welchem SAP-Benutzernamen die Aktionen im SAP ausgeführt werden. Das ist ein RFC-Benutzer. Wie (und an welchem Computer) erfolgt eigentlich die Anmeldung für den RFC-Benutzer? Wird dort überhaupt die normale Anmeldung per SAPGUI gemacht? Oder reicht es aus, wenn an dem Computer SAPGUI 720 einfach nur installiert ist?
Habt Ihr auch das Problem mit einer Zeichenfolge die mehr als ein @-Zeichen am Stück enthält? Kannst Du den Fehler schon im SAP-System sehen (und damit dort ggf. debuggen), oder ist es nur, wie in unserem Fall, dass das extrene System mit irgendwelchen Fehlermeldungen endet, aber im SAP praktisch gar nichts passiert? (KMir wurde dazu noch gesagt, dass ein Prozess im SAP schon gestartet wurde, und der musste immer wieder extra gekillt werden, sonst kam es nie zum Ende - ein Anzeichen, dass das SAP-Terrain doch bereits betreten war als der Fehler erschienen ist, aber zum konkreten Aufruf des Funktionsbausteins hat es nicht gereicht.
Ein Frage noch: Wie habt Ihr herausgefunden dass es u.U. mit dem SAPGUI zu tun haben könnte?
Viele Grüße
scsaba
[size=85](oder hast Du geglaubt, daß Du aus Dieser Nummer raus bist ?
)[/size][/quote]Hallo Jens,
zugegeben, das war mein erster Gedanke...
Aber wie man sieht, ich bin doch zurückgekommen weil ich gedanklich nicht darüber hinwegkommen kann...
Du sagst es liegt an der SAPGUI-Version - entschuldige die blöde Frage aber wie kommt das SAPGUI hier erst ins Spiel? Der extrene System ruft unseren RFC-Funktionsbaustein. Die Verbindung legt fest, unter welchem SAP-Benutzernamen die Aktionen im SAP ausgeführt werden. Das ist ein RFC-Benutzer. Wie (und an welchem Computer) erfolgt eigentlich die Anmeldung für den RFC-Benutzer? Wird dort überhaupt die normale Anmeldung per SAPGUI gemacht? Oder reicht es aus, wenn an dem Computer SAPGUI 720 einfach nur installiert ist?
Habt Ihr auch das Problem mit einer Zeichenfolge die mehr als ein @-Zeichen am Stück enthält? Kannst Du den Fehler schon im SAP-System sehen (und damit dort ggf. debuggen), oder ist es nur, wie in unserem Fall, dass das extrene System mit irgendwelchen Fehlermeldungen endet, aber im SAP praktisch gar nichts passiert? (KMir wurde dazu noch gesagt, dass ein Prozess im SAP schon gestartet wurde, und der musste immer wieder extra gekillt werden, sonst kam es nie zum Ende - ein Anzeichen, dass das SAP-Terrain doch bereits betreten war als der Fehler erschienen ist, aber zum konkreten Aufruf des Funktionsbausteins hat es nicht gereicht.
Ein Frage noch: Wie habt Ihr herausgefunden dass es u.U. mit dem SAPGUI zu tun haben könnte?
Viele Grüße
scsaba
Moin,
also im Packet des SAPGUI befinden sich folgende Controls mit denen RFC-Verbindungen realisiert werden:
hier die Details:
im Filesystem:
Die Controls sind Dateien vom Typ *.OCX auf Deiner Festpaltte, welche üblicherweise bei der SAPGUI installation auch in der Registry registriert werden.
Das heißt, wenn man "nur" RFC Kommunikation will, würden diese Controls ausreichen (und man spart ca. 500 MB Platz)
Das ist auch etwas, was ich noch genauer untersuchen will.
Mit einem neuen SAPGUI Patchlevel kann es sein, das auch die OCX Controls erneuert werden.
die Registry-Einträge
Die Eigenschaften eines Controls mit Versionsnr etc.
Die Verbindung zum Control in einer VB Anwendung
Die Antwort auf die Frage: woher kommt dieses "SAP.Logoncontrol.1" oder "SAP.Functions" ?
seit geraumer Zeit gibt es auch eine Unicode-Variante des Controls, was mich vermuten ließ, das hier das Problem mit @@@ liegen könnte.
Derzeit habe ich für SAPGUI-Inst. eine virtuelle Maschine aufgesetzt mit Win7 x32.
Die Maschine besitzt einen sogenannten "Snapshot", ein Wiederaufsetzpunkt, um SAPGUI zu installieren und nach den Tests wieder
zu 100% de-installieren.
Ich möchte ausschliessen, daß Reste nach einer De-installation auf der Festplatte/Registry verbleiben.
gruß Jens
also im Packet des SAPGUI befinden sich folgende Controls mit denen RFC-Verbindungen realisiert werden:
hier die Details:
im Filesystem:
Die Controls sind Dateien vom Typ *.OCX auf Deiner Festpaltte, welche üblicherweise bei der SAPGUI installation auch in der Registry registriert werden.
Das heißt, wenn man "nur" RFC Kommunikation will, würden diese Controls ausreichen (und man spart ca. 500 MB Platz)
Das ist auch etwas, was ich noch genauer untersuchen will.
Mit einem neuen SAPGUI Patchlevel kann es sein, das auch die OCX Controls erneuert werden.
die Registry-Einträge
Die Eigenschaften eines Controls mit Versionsnr etc.
Die Verbindung zum Control in einer VB Anwendung
Die Antwort auf die Frage: woher kommt dieses "SAP.Logoncontrol.1" oder "SAP.Functions" ?
seit geraumer Zeit gibt es auch eine Unicode-Variante des Controls, was mich vermuten ließ, das hier das Problem mit @@@ liegen könnte.
Derzeit habe ich für SAPGUI-Inst. eine virtuelle Maschine aufgesetzt mit Win7 x32.
Die Maschine besitzt einen sogenannten "Snapshot", ein Wiederaufsetzpunkt, um SAPGUI zu installieren und nach den Tests wieder
zu 100% de-installieren.
Ich möchte ausschliessen, daß Reste nach einer De-installation auf der Festplatte/Registry verbleiben.
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.
Hallo Jens, nur aus purem Interesse: konntest Du in der Zwischenzeit etwas herauskriegen?
Ich würde gerne erfahren ob und wie Du das Problem gelöst hast. (Bei mir tut sich diesbezüglich bestimmt nichst mehr, ich bin mittlerweile sehr weit weg vom Thema).
Danke und Gruß,
scsaba
Ich würde gerne erfahren ob und wie Du das Problem gelöst hast. (Bei mir tut sich diesbezüglich bestimmt nichst mehr, ich bin mittlerweile sehr weit weg vom Thema).
Danke und Gruß,
scsaba
Moin scsaba,
Alle Versionen des SAPGUI die ich getestet hatte, verhielten sich so wie sie sollten.
Sämtliche "Probleme" wurden von der RFC-Anwendung verursacht und waren Programmierfehler.
gruß Jens
Alle Versionen des SAPGUI die ich getestet hatte, verhielten sich so wie sie sollten.
Sämtliche "Probleme" wurden von der RFC-Anwendung verursacht und waren Programmierfehler.
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.
Vergleichbare Themen
2
Antw.
Antw.
1748
Views
Views
3
Antw.
Antw.
2119
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
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.