fehlerhafte Datenbanktabelle
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.Die Anpassung (führende Nullen beim Ablegen der Daten auf der DB) habe ich nun vorgenommen.
Die Daten werden jetzt richtig angezeigt.
Was mir aber aufgefallen ist, dass obwohl der Wert nun mit führenden Nullen abgespeichert wurde, in der SE16N in Spalte „unkonvertiert“ der Wert ohne führende Nullen angezeigt wird. Beim Selektieren, wird dieser aber mit führenden Nullen angezeigt.
Das haben wir bei anderen Systemen nicht.
Aber das grundsätzliche Problem ist behoben, also habe ich das Thema mal als gelöst markiert
Vielen Dank für die Unterstützung!
Liebe Grüße
abuma
Die Daten werden jetzt richtig angezeigt.
Was mir aber aufgefallen ist, dass obwohl der Wert nun mit führenden Nullen abgespeichert wurde, in der SE16N in Spalte „unkonvertiert“ der Wert ohne führende Nullen angezeigt wird. Beim Selektieren, wird dieser aber mit führenden Nullen angezeigt.
Das haben wir bei anderen Systemen nicht.
Aber das grundsätzliche Problem ist behoben, also habe ich das Thema mal als gelöst markiert
Vielen Dank für die Unterstützung!
Liebe Grüße
abuma
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1933 / 252 /
410
)
»
Ich vermute, dass "Wert unkonvertiert" trotzdem den CONVERSION EXIT durchläuft und nur z.B. Datümer im internen Format 20180218 statt 18.02.2018 anzeigt. In Table Controls sind die Conversion Exits fast immer aktiv, und die SE16N ist ja Table Control-basiert.
Ich persönlich nehme sowieso lieber die alte SE16, aber jedem Tierchen sein Pläsierchen.
Ich persönlich nehme sowieso lieber die alte SE16, aber jedem Tierchen sein Pläsierchen.
Conversion Exits sind generell immer aktiv, sofern ein Bezug zum DDIC besteht (und ein KonvExit definiert ist, natürlich...).DeathAndPain hat geschrieben:In Table Controls sind die Conversion Exits fast immer aktiv,
Das stimmt nicht! Die SE16n stellt die Daten in einem ALV-Grid dar.DeathAndPain hat geschrieben:und die SE16N ist ja Table Control-basiert.
Die SE16 verwendet eine ALV-Liste, was jedoch auf auf die Grid-Darstellung umgestellt werden kann.
In beiden Transaktionen kann der Konvertierungsexit ausgeschaltet werden.
In der SE16n werden bei in der Standardeinstellung bei einem Doppelklick auf die Zeile beide Werte (Mit Konvertierungsexit und unkonvertiert) angezeigt. Das Verhalten kann ebenfalls in den Einstellungen geändert werden.
Beitrag
von DeathAndPain (Top Expert / 1933 / 252 /
410
)
»
Das stimmt doch, denn die Rede war von der Spalte "unkonvertiert", und die gibt es in der SE16N nur, wenn man auf eine Zeile doppelklickt. Und dann macht die SE16N ein Table Control mit den Detailwerten dieser Zeile auf.Das stimmt nicht! Die SE16n stellt die Daten in einem ALV-Grid dar.und die SE16N ist ja Table Control-basiert.
Das stimmt.DeathAndPain hat geschrieben:Das stimmt doch, denn die Rede war von der Spalte "unkonvertiert", und die gibt es in der SE16N nur, wenn man auf eine Zeile doppelklickt. Und dann macht die SE16N ein Table Control mit den Detailwerten dieser Zeile auf.Das stimmt nicht! Die SE16n stellt die Daten in einem ALV-Grid dar.und die SE16N ist ja Table Control-basiert.
Das Popup ist allerdings nicht die Basis der SE16n.
Wie die Daten technisch dargestellt werden ist allerdings auch egal.
Egal, ob ein Wert per WRITE, in einer ALV-Liste, in einem ALV-Grid, einem Dynprofeld, einem TableControl ausgegeben wird, es wird immer per Default der dahinterliegende Konvertierungsexit verwendet. Soll er nicht verwendet werden, so muss er ausgeschaltet/ ignoriert werden.
Bei "Wert unkonvertiert" wird kein Konvertierungsexit durchlaufen.
Daher müsste doch der Wert in dieser Spalte auch mit führenden Nullen angezeigt werden?ewx hat geschrieben:Bei "Wert unkonvertiert" wird kein Konvertierungsexit durchlaufen.
Mit den Einstellungen meintest du die Einstellung in der SE16N bei der ich den durchlauf des Konv.Exits verhindern kann oder?
Mit dieser Einstellung würden ja dann auch die Spalten der gewohnten Anzeige mit führenden Nullen angezeigt werden.
Kennen und erwarten würde ich halt von der Spalte unkonvertiert, dass hier die führenden Nullen angezeigt werden.
Kennt jemand eine Erklärung hierfür warum dies nicht der Fall ist?
Liebe Grüße
abuma
Ja. Es gibt keine.abuma hat geschrieben:Kennen und erwarten würde ich halt von der Spalte unkonvertiert, dass hier die führenden Nullen angezeigt werden.
Kennt jemand eine Erklärung hierfür warum dies nicht der Fall ist?
Wenn das Feld SAKNR, das vom Typ CHAR(10) ist und den Konvertierungsexit ALPHA hinterlegt hat, aus einem CHAR10-Feld ohne Konvertierungsexit ALPHA gefüllt wurde, dann steht dort eben nicht 0000012345, sondern nur 12345.
Aber der Insert auf die DB wird ja mit einer Struktur vom Typ der Tabelle gemacht. Der Wert des Kontos wird vorher mit Fuba CONVERSION_EXIT_ALPHA_INPUT konvertiert.ewx hat geschrieben:Ja. Es gibt keine.abuma hat geschrieben:Kennen und erwarten würde ich halt von der Spalte unkonvertiert, dass hier die führenden Nullen angezeigt werden.
Kennt jemand eine Erklärung hierfür warum dies nicht der Fall ist?
Wenn das Feld SAKNR, das vom Typ CHAR(10) ist und den Konvertierungsexit ALPHA hinterlegt hat, aus einem CHAR10-Feld ohne Konvertierungsexit ALPHA gefüllt wurde, dann steht dort eben nicht 0000012345, sondern nur 12345.
In die Struktur kannst du rein schreiben, was du willst... Da wird kein Konvertierungsexit mehr durchlaufen!abuma hat geschrieben:Aber der Insert auf die DB wird ja mit einer Struktur vom Typ der Tabelle gemacht. Der Wert des Kontos wird vorher mit Fuba CONVERSION_EXIT_ALPHA_INPUT konvertiert.
Sorry aber ich versteh deine Aussage denke ich gerade nicht ganz.ewx hat geschrieben:In die Struktur kannst du rein schreiben, was du willst... Da wird kein Konvertierungsexit mehr durchlaufen!abuma hat geschrieben:Aber der Insert auf die DB wird ja mit einer Struktur vom Typ der Tabelle gemacht. Der Wert des Kontos wird vorher mit Fuba CONVERSION_EXIT_ALPHA_INPUT konvertiert.
Mein Feld SAKNR vom Typ CHAR(10) mit Konvertierungsexit ALPHA wird aus einem CHAR10-Feld mit Konvertierungsexit ALPHA gefüllt, d.h. es müsste doch 0000012345 statt 12345 in der Spalte unkonvertiert stehen.ewx hat geschrieben:Ja. Es gibt keine.abuma hat geschrieben:Kennen und erwarten würde ich halt von der Spalte unkonvertiert, dass hier die führenden Nullen angezeigt werden.
Kennt jemand eine Erklärung hierfür warum dies nicht der Fall ist?
Wenn das Feld SAKNR, das vom Typ CHAR(10) ist und den Konvertierungsexit ALPHA hinterlegt hat, aus einem CHAR10-Feld ohne Konvertierungsexit ALPHA gefüllt wurde, dann steht dort eben nicht 0000012345, sondern nur 12345.
In den anderen Systemen klappt das ja auch daher hat mich das einfach nur verwirrt und es würde mich einfach nur interessieren warum das so ist.
Beitrag
von DeathAndPain (Top Expert / 1933 / 252 /
410
)
»
Nein, das ist nicht richtig. Man kann bei all diesen Ausgabemöglichkeiten den Conversion Exit verwenden, aber automatisch passiert das keineswegs in allen Fällen. Bestes Gegenbeispiel ist die alte SE16. In deren Hauptliste, die wohl noch auf WRITE basiert, stehen die Werte unkonvertiert drin. Ein wesentlicher Grund, weshalb ich sie so schätze.Egal, ob ein Wert per WRITE, in einer ALV-Liste, in einem ALV-Grid, einem Dynprofeld, einem TableControl ausgegeben wird, es wird immer per Default der dahinterliegende Konvertierungsexit verwendet. Soll er nicht verwendet werden, so muss er ausgeschaltet/ ignoriert werden.
Sorry: Wenn du schreibst, dass der KonvExit vorher durchlaufen wird, dann ist meine Aussage natürlich quatsch. Ich glaube - und das wurde ja bereits vermutet - dass es genau da einen Fehler gibt oder gab.abuma hat geschrieben:Sorry aber ich versteh deine Aussage denke ich gerade nicht ganz.ewx hat geschrieben:In die Struktur kannst du rein schreiben, was du willst... Da wird kein Konvertierungsexit mehr durchlaufen!abuma hat geschrieben:Aber der Insert auf die DB wird ja mit einer Struktur vom Typ der Tabelle gemacht. Der Wert des Kontos wird vorher mit Fuba CONVERSION_EXIT_ALPHA_INPUT konvertiert.
Das wirst du selber herausfinden müssen. Wir können nur vermuten, was der Grund sein könnte.abuma hat geschrieben:Mein Feld SAKNR vom Typ CHAR(10) mit Konvertierungsexit ALPHA wird aus einem CHAR10-Feld mit Konvertierungsexit ALPHA gefüllt, d.h. es müsste doch 0000012345 statt 12345 in der Spalte unkonvertiert stehen.ewx hat geschrieben:Ja. Es gibt keine.abuma hat geschrieben:Kennen und erwarten würde ich halt von der Spalte unkonvertiert, dass hier die führenden Nullen angezeigt werden.
Kennt jemand eine Erklärung hierfür warum dies nicht der Fall ist?
Wenn das Feld SAKNR, das vom Typ CHAR(10) ist und den Konvertierungsexit ALPHA hinterlegt hat, aus einem CHAR10-Feld ohne Konvertierungsexit ALPHA gefüllt wurde, dann steht dort eben nicht 0000012345, sondern nur 12345.
In den anderen Systemen klappt das ja auch daher hat mich das einfach nur verwirrt und es würde mich einfach nur interessieren warum das so ist.
Wenn in dem Feld "unkonvertierter Wert" keine führenden Nullen stehen, dann wurde der Wert OHNE Konv.Exit geschrieben. Und das sieht eben nach einem Fehler in der Applikation aus und nicht nach einer Inkonsistenz der DB.
Gibt es noch andere Programme, die in die Tabelle schreiben?
Sind *alle* DB-Operationen richtig? Also auch evtl. UPDATEs?
Dann hast du das in den Einstellungen für die SE16 deaktiviert. Siehe Screenshot "Einstellung-SE16"DeathAndPain hat geschrieben:Nein, das ist nicht richtig. Man kann bei all diesen Ausgabemöglichkeiten den Conversion Exit verwenden, aber automatisch passiert das keineswegs in allen Fällen. Bestes Gegenbeispiel ist die alte SE16. In deren Hauptliste, die wohl noch auf WRITE basiert, stehen die Werte unkonvertiert drin. Ein wesentlicher Grund, weshalb ich sie so schätze.Egal, ob ein Wert per WRITE, in einer ALV-Liste, in einem ALV-Grid, einem Dynprofeld, einem TableControl ausgegeben wird, es wird immer per Default der dahinterliegende Konvertierungsexit verwendet. Soll er nicht verwendet werden, so muss er ausgeschaltet/ ignoriert werden.
Die Einstellung gibt es auch in der SE16n.
Bei allem, bei dem du eine Dictionary-Verknüpfung hast, werden die Dictionary-Einstellungen auch verwendet. Und dazu gehört auch der Konvertierungsexit.
Wenn du ein Feld auf dem Dynpro mit Bezug zum DDIC anlegst, dann wird der KonvExit durchlaufen.
Wenn du eine interne Tabelle ausgibst, die Bezug zum DDIC hat, dann wird der Konv.Exit berücksichtigt.
Du musst in allen Fällen die Verbindung zum DDIC aktiv lösen. Siehe Screenshot "Quelltext SE16".
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
So ich habe mir jetzt mal die DB-Tabelle BSEG angesehen.
Die Felder dort werden in der Spalte unkonvertiert ebenfalls ohne führende Nullen angezeigt. Bspw. Feld HKONT
Wenn ich in der SE16N im Menü auf Zusätze -> Einstellungen ändern gehe und "Ausgabe ohne Konvertierungsexit" anhake werden die Werte dennoch ohne führende Nullen angezeigt.
In der SE16 wird es mir korrekt angezeigt.
Vermutlich passt was bei der SE16N nicht.
Falls ich dazu bei Gelegenheit noch mehr rausfinde bzw. die Ursache des Problems finden sollte schreib ich es hier rein
Weitere Antworten erwarte ich jetzt auch nicht von euch, ihr habt ja das System nicht vor euch.
Aber recht herzlichen Dank für eure Antworten!
Liebe Grüße
abuma
Die Felder dort werden in der Spalte unkonvertiert ebenfalls ohne führende Nullen angezeigt. Bspw. Feld HKONT
Wenn ich in der SE16N im Menü auf Zusätze -> Einstellungen ändern gehe und "Ausgabe ohne Konvertierungsexit" anhake werden die Werte dennoch ohne führende Nullen angezeigt.
In der SE16 wird es mir korrekt angezeigt.
Vermutlich passt was bei der SE16N nicht.
Falls ich dazu bei Gelegenheit noch mehr rausfinde bzw. die Ursache des Problems finden sollte schreib ich es hier rein
Weitere Antworten erwarte ich jetzt auch nicht von euch, ihr habt ja das System nicht vor euch.
Aber recht herzlichen Dank für eure Antworten!
Liebe Grüße
abuma
Das ist merkwürdig. Aber das wussten wir ja bereits...
In "meinem" System ist das definitiv nicht so.
Kannst du denn dort die Einträge HKONT selektieren?
Und um sicher zu gehen: BSEG-HKONT ist die Domäne SAKNR zugeordnet und SAKNR hat den ConvExit ALPHA?
In "meinem" System ist das definitiv nicht so.
Kannst du denn dort die Einträge HKONT selektieren?
Und um sicher zu gehen: BSEG-HKONT ist die Domäne SAKNR zugeordnet und SAKNR hat den ConvExit ALPHA?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Vergleichbare Themen
4
Antw.
Antw.
2640
Views
Views
2
Antw.
Antw.
7437
Views
Views
analog COGI: Fehlerhafte Warenbewegungen im Hintergrund
von hsiebert » 05.09.2007 11:31 • Verfasst in Material Management & Produktionsplanung
von hsiebert » 05.09.2007 11:31 • Verfasst in Material Management & Produktionsplanung
1
Antw.
Antw.
591
Views
Views
Fehlerhafte FAX-Sendungen (SCOT) erneut anstoßen - Job
von f.weissenberger » 23.09.2019 13:03 • Verfasst in ABAP® für Anfänger
von f.weissenberger » 23.09.2019 13:03 • Verfasst in ABAP® für Anfänger
2
Antw.
Antw.
1723
Views
Views
fehlerhafte Ausgabe einer internen Tabelle im Popup
von Alexander D. » 13.03.2007 12:11 • Verfasst in ABAP® Core
von Alexander D. » 13.03.2007 12:11 • Verfasst in ABAP® Core
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
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 12 Stunden von DeathAndPain 2 / 230
vor 12 Stunden von DeathAndPain 2 / 230
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 12 Stunden von DeathAndPain 2 / 230
vor 12 Stunden von DeathAndPain 2 / 230