SELECT funktioniert nicht
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
15 Beiträge
•
Seite 1 von 1
15 Beiträge
Seite 1 von 1
Ich habe ein seltsames Problem: Ein simpler SELECT auf die Tabelle VTTK funktioniert nicht. Ich habe schon alle Schreibweisen für den Inhalt von LV_TKNUM getestet. Immer liefert dieses winzige Coding Subrc 4. Die SE11 oder SE16n liefern saubere Ergebnisse und finden den Beleg.
Hier läuft ein altes Release 4.6c
Hat jemand eine Idee?
Ciao,
Burkhart
Code: Alles auswählen.
DATA: lv_tknum type tknum value '2000071 ',
ls_vttk TYPE VTTK.
SELECT single * FROM vttk
INTO ls_vttk
WHERE tknum = lv_tknum.
Hat jemand eine Idee?
Ciao,
Burkhart
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Die Transportnummer hat nur 7 Stellen. Funktioniert es, wenn mit führenden Nullen augefüllt wird?
Code: Alles auswählen.
DATA: lv_tknum type tknum value '0002000071 ',
ls_vttk TYPE VTTK.
SELECT single * FROM vttk
INTO ls_vttk
WHERE tknum = lv_tknum.
Publikationen:
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
@jocoder: "Qualitätsmanagement in der ABAP-Entwicklung," und dann solche Vorschläge :(.
An der Domäne TKNUM hängt doch einen ALPHA-Konvertierung. Daher hier den Fuba CONVERSION_EXIT_ALPHA_INPUT verwenden. Alles andere ist unsauber.... Wobei, da gab es doch in der neue Syntax eine Kurzform
Code: Alles auswählen.
data(lv_text) = |{ textstring ALPHA = IN }|
@msfox
Wie mit führenden Nullen aufgefüllt wird, darüber wurde keine Aussage getroffen. Dies war nur ein pragmatischer Ansatz auf die Frage von @Nordlicht. Das Codebeispiel kann in dieser Form sowieso nicht im Produktivsystem verwendet werden (Magic-Numbers).
Wenn wir beim Thema Clean-Code sind, ist der Einsatz von Konvertierungsroutinen eher ein Anti-Pattern, denn es zu vermeiden gilt. Die Anwendung von Konvertierungsroutinen überlässt man in ABAP-Reports lieber der Selektionsbildverarbeitung.
Aber in Zukunft keine Aussagen kommentieren, die so gar nicht getroffen wurden.
Wie mit führenden Nullen aufgefüllt wird, darüber wurde keine Aussage getroffen. Dies war nur ein pragmatischer Ansatz auf die Frage von @Nordlicht. Das Codebeispiel kann in dieser Form sowieso nicht im Produktivsystem verwendet werden (Magic-Numbers).
Wenn wir beim Thema Clean-Code sind, ist der Einsatz von Konvertierungsroutinen eher ein Anti-Pattern, denn es zu vermeiden gilt. Die Anwendung von Konvertierungsroutinen überlässt man in ABAP-Reports lieber der Selektionsbildverarbeitung.
Aber in Zukunft keine Aussagen kommentieren, die so gar nicht getroffen wurden.
Folgende Benutzer bedankten sich beim Autor jocoder für den Beitrag:
DeathAndPain
Publikationen:
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Sehe ich auch so. Ein Code sollte möglichst sprechend ausdrücken, was er tut, damit er gut lesbar ist. Wenn links mit Nullen aufgefüllt werden soll, ist es besser nachvollziehbar, wenn der Code genau dies erkennbar tut, als wenn er irgendein Konvertierungsexit aufruft und man erst überlegen muss, was dessen Funktionsweise gewesen ist.
Deshalb bin ich übrigens auch gegen den Einsatz sinnloser Konstanten.
IF wert = 6.
ist besser lesbar als
IF wert = gc_sechs.
Da kann man dann zwar vermuten, was in gc_sechs sicherlich drin sein wird, aber um sicher zu sein, keinen Fehler zu machen, muss man es erst nachsehen, und auch von der Lesbarkeit her macht es sich schlechter. Konstanten sind gut, wenn eine Änderung in der Zukunft theoretisch denkbar ist und man dann nicht alle Programmstellen, an denen der Wert verwendet wird, einzeln nachändern müssen will, aber nicht bei solchen Werten. Deshalb bin ich auch so ketzerisch, von abap_true statt 'X' wenig zu halten (wobei das in dem Fall von der Lesbarkeit her noch geht).
Deshalb bin ich übrigens auch gegen den Einsatz sinnloser Konstanten.
IF wert = 6.
ist besser lesbar als
IF wert = gc_sechs.
Da kann man dann zwar vermuten, was in gc_sechs sicherlich drin sein wird, aber um sicher zu sein, keinen Fehler zu machen, muss man es erst nachsehen, und auch von der Lesbarkeit her macht es sich schlechter. Konstanten sind gut, wenn eine Änderung in der Zukunft theoretisch denkbar ist und man dann nicht alle Programmstellen, an denen der Wert verwendet wird, einzeln nachändern müssen will, aber nicht bei solchen Werten. Deshalb bin ich auch so ketzerisch, von abap_true statt 'X' wenig zu halten (wobei das in dem Fall von der Lesbarkeit her noch geht).
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Wobei das Aufrufen des zum Feld gehörenden Konvertierungsexits zumindest schon mal zum Ausdruck bringt, dass derjenige erkannt hat, dass ein Konvertierungsexit an dem Feld hängt und damit auch gleicht dokumentiert dass das Auffüllen mit Nullen nicht aus Jux passiert sondern weil das Feld das so benötigt. Und ich erwarte eigentlich von jedem erfahrenen Entwickler dass das Aufrufen eines Konvertierungsexits nicht mehr zu irgendwelchen Überlegungen führt sondern dass man weiß was da passiert und man nur noch schaut ob es der ...INPUT oder ...OUTPUT ist.DeathAndPain hat geschrieben: ↑13.08.2020 09:43Wenn links mit Nullen aufgefüllt werden soll, ist es besser nachvollziehbar, wenn der Code genau dies erkennbar tut, als wenn er irgendein Konvertierungsexit aufruft und man erst überlegen muss, was dessen Funktionsweise gewesen ist.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 3):
msfox • ST22 • qyurryus
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Das ist doch kein Antipattern. Nicht jedes Programm hat Selektionsbilder wo man das vom Kernel machen lassen kann.
Die Mehrzahl aller Programme welche ich schreibe und die mit externen Daten agieren müssen haben am Anfang erst mal eine Reihe Konvertierungen in die internen Formate. Und ich werde den Teufel tun hier Konvertierungsexits zu vermeiden.
Konvertierungsexits sind ein ganz normales Werkzeug welches zur Umwandlung von interne in externe Formate verwendet werden sollte.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
ST22 • qyurryus
In dem Fall ist es aber einfach FALSCH hier pauschal mit Vornullen aufzufüllen. Die Domäne TKNUM ist vom Type CHAR10. Dort können also auch Buchstaben drauf stehen. Ist dies der Fall, so darf NICHT mit Vornullen aufgefüllt werden.DeathAndPain hat geschrieben: ↑13.08.2020 09:43Sehe ich auch so. Ein Code sollte möglichst sprechend ausdrücken, was er tut, damit er gut lesbar ist. Wenn links mit Nullen aufgefüllt werden soll, ist es besser nachvollziehbar, wenn der Code genau dies erkennbar tut,
Nutzt man gleich von Anfang an die ALPHA-Konvertierung, braucht man sich solche Belange keine Gedanken machen.
Für den einfachen Test vom TE hat der Vorschlag ja gereicht. Aber dann kam vom TE:
Genau der eine Fall läuft - super. Vielleicht schlummern in der Datenbank aber 100 andere Fälle die mit auffüllen von 4 Vornullen nicht laufen....
Das ist so auch nicht richtig. Bzw.: Ich sehe gerade, dass man das auch anders interpretieren kann... Wenn ein Buchstabe vorkommt, dann darf nicht mit Nullen aufgefüllt werden. Ich hatte es so interpretiert, dass alleine die Möglichkeit, dass Buchstaben vorkommen können, ein Auffüllen mit Nullen ausschließt...
In der Regel wird eine Zahl in eine Nummer mit führenden Nullen umgewandelt (Konvertierungsexit, Alpha-Konvertierung). Wenn ein Buchstabe mit drin ist, dann wird NICHT mit Nullen aufgefüllt. "T1000" bleibt also "T1000" und wird nicht zu "00000T1000". Aus "1000" wird aber "0000001000".
Eine Ausnahme bilden m.W. Materialnummern. Da kann es durchaus sein, dass eine MATNR mit "0" beginnt, ohne dass die ganzen 18 bzw. 40 Stellen aufgefüllt werden. Es kann also durchaus eine Materialnummer "0050000" geben.
Im Übrigen gehe ich davon aus, dass es sich eh um ein Testprogramm handelt.
Da empfiehlt es sich, die Vorbelegung mit PARAMETERS ... DEFAULT 'xyz' zu machen, denn dann wird die richtige Konvertierungsroutine durchlaufen.
Wenn man sich nicht sicher ist, wo der Wert herkommt (Stichwort Schnittstellen), dann sollte immer der entspr. Konvertierungsexit aufgerufen werden, denn dieser kann, wie z.B. bei Materialnummern, sehr kompliziert sein.
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Bei Materialnummern ist customizbar ob ALPHA-Konvertierung verwendet wird oder nicht und noch einiges mehr. Ich habe sowohl Kunden die mit führenden Nullen auffüllen als auch solche welche das nicht tun. Und hier zeigt sich eben der Vorteil des Konvertierungsexits. Ich muss nicht im Customizing nachschauen was im System eingestellt ist sondern lasse einfach den Exit MATN1 drüberlaufen und der macht es "richtig"
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
msfox
Ich wollte schon immer mal eine generell nutzbare Routine haben, die man funktional aufrufen kann:
github: conversion exit
github: conversion exit
Code: Alles auswählen.
tknum = zcl_trcktrsr_conversion_exit=>for_rollname( 'TKNUM' )->input( '12345' ).<kleinlich an>
Wenn das die MATN1-Konvertierung macht, dann ist es keine "ALPHA-Konvertierung"
<kleinlich aus> :)
Kann bei Materialnummern dann die Konvertierung MATN1, wie in der Domäne MATNR fest hinterlegt, übersteuern?black_adept hat geschrieben: ↑13.08.2020 11:18Bei Materialnummern ist customizbar ob ALPHA-Konvertierung verwendet wird oder nicht und noch einiges mehr.
Wenn das die MATN1-Konvertierung macht, dann ist es keine "ALPHA-Konvertierung"
<kleinlich aus> :)
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Man kann MATN1 so customizen, dass das Ergebnis von MATN1 und ALPHA für alle Eingaben gleich ist. Dazu muss man nur ein Ankreuzfeld nicht setzen und die Länge auf die maximale Materialnummernlänge setzen ( üblicherweise 18 oder 40 ). Und in diesem Fall ist dann eine MATN1 Konvertierung äquivalent zur ALPHA Konvertierung.
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
1406
Views
Views
2
Antw.
Antw.
859
Views
Views
Job hängt an select, wie herausfinden welches select
von dpz » 01.08.2019 10:23 • Verfasst in ABAP® Core
von dpz » 01.08.2019 10:23 • Verfasst in ABAP® Core
4
Antw.
Antw.
9457
Views
Views
Performance: SELECT UP TO 1 ROWS vs. SELECT SINGLE
von roman1983 » 04.09.2008 14:29 • Verfasst in ABAP® für Anfänger
von roman1983 » 04.09.2008 14:29 • Verfasst in ABAP® für Anfänger
4
Antw.
Antw.
18932
Views
Views
Select nach Parameter & Select-Options
von doeme » 10.07.2012 16:37 • Verfasst in ABAP® für Anfänger
von doeme » 10.07.2012 16:37 • Verfasst in ABAP® für Anfänger
10
Antw.
Antw.
6978
Views
Views
2 Select-Options zu einem für Select zusammenfügen
von manuk » 23.03.2005 11:02 • Verfasst in ABAP® Core
von manuk » 23.03.2005 11:02 • 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
SAPScript Formular Fertigungspapiere doppelseitig Drucken
vor einer Woche von Abap_neuling 14 / 3361
vor einer Woche von Abap_neuling 14 / 3361
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor einer Woche von a-dead-trousers 5 / 2889
vor einer Woche von a-dead-trousers 5 / 2889
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
SAPScript Formular Fertigungspapiere doppelseitig Drucken
vor einer Woche von Abap_neuling 14 / 3361
vor einer Woche von Abap_neuling 14 / 3361
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor einer Woche von a-dead-trousers 5 / 2889
vor einer Woche von a-dead-trousers 5 / 2889