Fremdschlüsselprüfung im ALV Grid

Re: Fremdschlüsselprüfung im ALV Grid

@Enno: Du schreibst am Anfang über "ein Datenelement für das Festwerte hinterlegt sind". Meinst du damit ein Datenelement mit einer Domäne mit Festwerten? Wenn ja: Verhält sich der Grid eigentlich anders, wenn du ein Datenelement nimmst, welches die Fremdschlüssel über eine referenzierte Wertetabelle definiert.

Re: Fremdschlüsselprüfung im ALV Grid

gtoXX hat geschrieben: ↑

12.10.2024 12:17

Ich sehe das nicht als Fehler aus der Sicht der Konsistenz. Es spielt keine Rolle ob es ein Schlüsselfeld ist oder nicht. Die Domäne sieht ein leeres Feld nicht vor, somit würde auch kein Programm ein leeres Feld erwarten.

Finde ich nicht. Während man für ein Schlüsselfeld bei z.B. FKTYP betriebswirtschaftlich noch so argumentieren könnte ("Ein Fakturabeleg MUSS immer einen gültigen Fakturatyp haben, sonst ist der gesamte Beleg fehlerhaft"), gibt es nun wirklich Unmengen von Möglichkeiten in denen die Eingabe leer sein darf (Fast immer bei der Definition von Customizing z.B.). Die Entscheidung darüber muss immer in der Applikation liegen und nicht in der Domäne.

Plus: Wieso sollte das Verhalten unterschiedlich sein, je nachdem ob die Werte als Festwerte oder in einer Prüftabelle definiert sind? Leuchtet mir nicht ein.

In einer Dynpro-Listbox ist es IMO genau richtig: du kannst ein Feld referenzieren, das Festwerte hat. Wenn es eine Musseingabe ist, dann stehen auch nur die Werte zur Verfügung, die in der Domäne definiert sind. Bei Kanneingabe, gibt es einen zusätzlichen leeren Eintrag.

Funfact: Wenn du ein Feld mit Musseingabe definierst, dessen Referenz in den Festwerten SPACE hat, kannst du SPACE nicht als Wert verwenden!