fehlerhafte Datenbanktabelle

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Getting started ... Alles für einen gelungenen Start.
48 Beiträge • Vorherige Seite 2 von 4 (current) Nächste
48 Beiträge Vorherige Seite 2 von 4 (current) Nächste

Re: fehlerhafte Datenbanktabelle

Beitrag von abuma (Specialist / 102 / 36 / 14 ) »
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

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: fehlerhafte Datenbanktabelle

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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.

Re: fehlerhafte Datenbanktabelle

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
DeathAndPain hat geschrieben:In Table Controls sind die Conversion Exits fast immer aktiv,
Conversion Exits sind generell immer aktiv, sofern ein Bezug zum DDIC besteht (und ein KonvExit definiert ist, natürlich...).
DeathAndPain hat geschrieben:und die SE16N ist ja Table Control-basiert.
Das stimmt nicht! Die SE16n stellt die Daten in einem ALV-Grid dar.
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.

Re: fehlerhafte Datenbanktabelle

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
und die SE16N ist ja Table Control-basiert.
Das stimmt nicht! Die SE16n stellt die Daten in einem ALV-Grid dar.
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.

Re: fehlerhafte Datenbanktabelle

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
DeathAndPain hat geschrieben:
und die SE16N ist ja Table Control-basiert.
Das stimmt nicht! Die SE16n stellt die Daten in einem ALV-Grid dar.
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.
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.

Re: fehlerhafte Datenbanktabelle

Beitrag von abuma (Specialist / 102 / 36 / 14 ) »
ewx hat geschrieben:Bei "Wert unkonvertiert" wird kein Konvertierungsexit durchlaufen.
Daher müsste doch der Wert in dieser Spalte auch mit führenden Nullen angezeigt werden?

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

Re: fehlerhafte Datenbanktabelle

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
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?
Ja. Es gibt keine.
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.

Re: fehlerhafte Datenbanktabelle

Beitrag von abuma (Specialist / 102 / 36 / 14 ) »
ewx hat geschrieben:
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?
Ja. Es gibt keine.
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.

Re: fehlerhafte Datenbanktabelle

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
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.
In die Struktur kannst du rein schreiben, was du willst... Da wird kein Konvertierungsexit mehr durchlaufen!

Re: fehlerhafte Datenbanktabelle

Beitrag von abuma (Specialist / 102 / 36 / 14 ) »
ewx hat geschrieben:
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.
In die Struktur kannst du rein schreiben, was du willst... Da wird kein Konvertierungsexit mehr durchlaufen!
Sorry aber ich versteh deine Aussage denke ich gerade nicht ganz.
ewx hat geschrieben:
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?
Ja. Es gibt keine.
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.
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.
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.

Re: fehlerhafte Datenbanktabelle

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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.
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.

Re: fehlerhafte Datenbanktabelle

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
abuma hat geschrieben:
ewx hat geschrieben:
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.
In die Struktur kannst du rein schreiben, was du willst... Da wird kein Konvertierungsexit mehr durchlaufen!
Sorry aber ich versteh deine Aussage denke ich gerade nicht ganz.
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:
ewx hat geschrieben:
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?
Ja. Es gibt keine.
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.
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.
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.
Das wirst du selber herausfinden müssen. Wir können nur vermuten, was der Grund sein könnte.
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?

Re: fehlerhafte Datenbanktabelle

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
DeathAndPain hat geschrieben:
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.
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.
Dann hast du das in den Einstellungen für die SE16 deaktiviert. Siehe Screenshot "Einstellung-SE16"
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".

Re: fehlerhafte Datenbanktabelle

Beitrag von abuma (Specialist / 102 / 36 / 14 ) »
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

Re: fehlerhafte Datenbanktabelle

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
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?

Vergleichbare Themen

4
Antw.
2213
Views
Fehlerhafte XML-Datei
von einar46 » 03.09.2014 21:56 • Verfasst in ABAP® Core
4
Antw.
2207
Views
ALV Grid OO fehlerhafte Filterung
von erich86 » 20.02.2014 00:07 • Verfasst in ABAP® für Anfänger
2
Antw.
6967
Views
2
Antw.
3213
Views
fehlerhafte workflows aus business-workplace entfernen?
von Loki » 20.08.2004 12:27 • Verfasst in ABAP Objects®
1
Antw.
473
Views
Fehlerhafte FAX-Sendungen (SCOT) erneut anstoßen - Job
von f.weissenberger » 23.09.2019 13:03 • Verfasst in ABAP® für Anfänger

Ü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

Zugriff auf Daten via Webdav
vor einer Stunde von msfox 2 / 37
Interne Tabelle
vor 18 Stunden von sap_enthusiast 3 / 163
Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 71

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zugriff auf Daten via Webdav
vor einer Stunde von msfox 2 / 37
Interne Tabelle
vor 18 Stunden von sap_enthusiast 3 / 163
Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 71

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 71
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141