fehlerhafte Datenbanktabelle

Re: fehlerhafte Datenbanktabelle

ewx hat geschrieben: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?

BSEG-HKONT ist der Domäne SAKNR zugeornet und hat den ConvExit ALPHA.

Aber... das Problem hat sich in Luft aufgelöst...
Ich habe gerade die SE16N gedebuggt, konnte nichts verdächtiges im Debugger feststellen und als ich dann raus aus dem Debugger bin und die Anzeige vor mir hatte, Stand im Feld unkonvertiert das HKONT mit führenden Nullen...

Wenn ich die SE16N jetzt aufrufe und mir die Daten anzeige (aus Tabelle BSEG oder auch aus meiner Z-Tabelle) wird alles richtig dargestellt.

Liebe Grüße
abuma

Re: fehlerhafte Datenbanktabelle

DeathAndPain hat geschrieben:

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".

Das ist wohl richtig. Für mich ist es aber der einzig richtige Ansatz, den Haken rauszunehmen. Ich meine, wozu verwendet man die SE16? Doch nicht für die tägliche Arbeit, sondern wenn man wissen möchte, was wirklich in der Datenbanktabelle drinsteht (und worauf man sich dementsprechend mit seinem SELECT wird einstellen müssen). Die SE16 ist ein Datenbanktool; da will man nicht Werte sehen, die völlig anders aussehen als die auf der Datenbank. (Deswegen ist es ja auch so verwerflich, wenn mit der SE16 produktiv gearbeitet wird, was freilich in der Realität durchaus vorkommt.)

Wer benutzerfreundlich-anschauliche Werte sehen möchte, der nimmt die SM30 oder die normalen Pflegetransaktionen für das jeweilige Sachgebiet.

SE16N kann alles, was SE16 kann und mehr und ist komfortabler. Das ist eher so ein alte Gewohnheitenproblem. Für mich gibt es keinen Einzigen Grund SE16 mehr einzusetzen. ^^

Re: fehlerhafte Datenbanktabelle

DeathAndPain hat geschrieben:Nene. Das fängt doch schon damit an, dass die SE16N in der Übersichtsliste alle Spaltenüberschriften als DDIC-Beschreibungstext anzeigt anstatt mit ihrem richtigen Datenbanknamen. Das ist doch Mist! ich will den Inhalt der Tabelle auf der Datenbank sehen, also will ich sehen, was z.B. im Feld KUNNR drinsteht und nicht im Feld "Kundennummer" - denn mit letzterem Begriff kann ich in meinem ABAP-Programm nichts anfangen. Nebenbei führt das auch dazu, dass die SE16N defaultmäßig alle Spalten so breit macht, dass der ganze DDIC-Beschreibungstext reinpasst - mit der Konsequenz, dass ich zunächst einmal nur einen Bruchteil der Spalten auf dem Bildschirm habe, den ich bei der SE16 hätte und rumscrollen muss.

Also von der Handhabung her gefällt mir die SE16N gar nicht. Die SE16 erfüllt perfekt ihre Funktion. Die soll mir einfach nur zeigen, wie es - wirklich! - auf der Datenbank aussieht. Da will ich keine Beschreibungstexte, keine Conversion Exits oder sonstigen kosmetisch verändernden Mist haben, sondern einfach nur das, was ich auch bekommen würde, wenn ich händisch einen SELECT eintippen und mir die Ausgabe anschauen würde. Und den Job macht die SE16 klar besser.

Edit: Auch die Konvertierung kannst du da ausschalten.

Re: fehlerhafte Datenbanktabelle

Schon besser. Aber ich hab das gerade gemacht und habe auch "Ausgabe ohne Konvertierungsexit" gesetzt, aber er zeigt mir dennoch die Personalnummer (TYPE PERSNO, das ist ein achtstelliges Feld vom Typ N) ohne führende Nullen, obwohl TYPE N immer führende Nullen auf der Datenbank hat. SE16 macht das nicht.

Re: fehlerhafte Datenbanktabelle

Und auch da gaukelt dir die Se16 was vor: Das Datum wird nämlich trotzdem benutzerfreundlich nach DD.MM.JJJJ konvertiert und nicht im internen Format JJJJMMDD angezeigt.

Das ist wahr, das kann man als kleine Schwachstelle der SE16 deuten - aber keine, die die SE16N nicht auch hätte. Wogegen ich mich auch nur gewehrt habe, war die Behauptung "SE16N kann alles, was SE16 kann and then some." In der SE16 kann ich auch schon Feldlängen abzählen und vergleichen. Im ALV der SE16N mit seiner Proportionalschrift geht das nicht. Und in der SE16 kann ich auch bei den ersten 10 Spalten die jeweils 5 ersten Zeichen mit Strg+Y markieren und kopieren. In der SE16N kriege ich mit Strg+Y nur ganzen Zellen markiert.

Dass eine "Typ-Ausgabe-Konvertierung" gemacht wird, finde ich auch gut, denn mit der internen Darstellung von gepackten Zahlen z.B. könnte ich nichts anfangen.

Sicherlich, IMHO sollte die inhaltlich so aussehen, wie man ein Literal des betreffenden Datentyps in ABAP schreiben würde. Also keine Grütze, aber auch keine kosmetischen Manipulationen, die für Endandwender gedacht sind. EInfach der echte Wert des Feldes in menschenlesbarer Form.

Abgesehen von dem von Dir erwähnten Schnitzer mit dem Datum macht die SE16 das auch. Und der Unterschied zur SE16N mit den führenden Nullen ist nicht unwichtig, denn es gibt in SAP viele Felder, die eigentlich numerisch sind, aber warum auch immer trotzden als TYP C und nicht N definiert sind (beispielsweise die Nummern von Kostenstellen. Ob die real auch Buchstaben enthalten dürfen, keine Ahnung. Ich kenne aber niemanden, der da welche nutzt.) Und wenn man z.B. in einem SELECT auf Initialwert vergleichen will, dann muss man angesichts der Tatsache, das IS INITIAL in einer WHERE-Bedingung nicht erlaubt ist, bei Typ N-Feldern schon auf so etwas wie '00000000' vergleichen. Und sowas will ich sehen können, indem ich mir per SE16 anschaue, in welcher Form die Werte auf der Datenbank liegen. Die SE16N lässt mich da im Stich.

Hingegen habe ich keine Probleme, dass ich in der SE16 keine Rohfassung gepackter Zahlen sehe, denn die brauche ich in ABAP in aller Regel auch nicht (also die gepackten Zahlen schon, aber ihre binären Wertangaben nicht).

Re: fehlerhafte Datenbanktabelle

Zumal die SE16N keine zusätzlichen Features bietet, in denen ich für meine Person einen Nutzen wahrnehmen würde.

Historisch (d.h. bei Einführung der SE16N) war es sogar so, dass diese auf den damaligen Systemen vergleichsweise langsam war und man mit der SE16 einfach schneller ein Ergebnis zu sehen bekommen hat. Dadurch ist die SE16N bei mir emotional noch zusätzlich negativ belegt, auch wenn dieses Argument heute keine Rolle mehr spielen dürfte.

Auf der anderen Seite kann ich mich erinnern, dass der WRITE-Befehl kurz nach Einführung der ALVs quälend langsam geworden ist. Rückblickend frage ich mich, ob das ein Kollateralschaden war oder gar eine gezielte Boshaftigkeit der SAP, um Entwickler zum Umstieg zu bewegen. Es wurden dadurch aber auch viele bereits bestehende, auf WRITE aufsetzende Reports langsam. War ziemlich ärgerlich.

Re: fehlerhafte Datenbanktabelle

Das war ziemlich offensichtlich, da schlagartig. Wir haben damals den größtmöglichen unterstützten Upgradeschritt gemacht, nämlich von 3.1i direkt auf 4.7. Danach waren Write-Listen extrem langsam, während die neuen ALVs einwandfrei performt haben. Mein subjektiver Eindruck ist, dass das auch nie wieder gefixt worden ist, aber mit zunehmender Hardwareleistung über die Jahre irgendwann egal gewesen ist.

Vielleicht hängt die miese Performance ja damit zusammen, dass bei dem Schritt auch OO eingeführt worden ist... *duckundweg*