TRY / ENTRY beim SELECT

Re: TRY / ENTRY beim SELECT

Schon <F1> auf 'TRY' versucht?

Re: TRY / ENTRY beim SELECT

Hi,

ja so habe ich es gemeint.

Bei INCLUDE's und Funktionsbausteinen kann man im TRY/ENDTRY mit CATCH eine Ausnahme abfangen wenn das gerufene Objekt nicht vorhanden ist.

Dieses möchte der Kunde jetzt auch bei einem SELECT bezüglich der genutzten Tabelle haben.

Der Hintergrund ist, dass die Entwicklungen beim Kunden sehr genau Paketen zugeordnet sind. Die Objekte dürfen paketübergreifend, wenn überhaupt, nur gerufen werden wenn der Aufruf über TRY/ENDTRY und CATCH abgefangen wird. Aus Paket A heraus wird eine Tabelle ZAXXXXX gefüllt, die auch diesem Paket zugeordnet ist. Diese soll jetzt in einer Funktion FBYYYYYY des Paketes B gelesen werden. Damit haben wir einen paketübergreifenden Zugriff. Jetzt soll auch hier über TRY/ENDTRY und CATCH verhindert werden, dass der SELECT ausgeführt wird wenn die Tabelle nicht vorhanden ist. Die Intention verstehe ich nicht, weil das Coding a)entweder nicht generiert werden kann wenn die Tabelle beim Transport nicht im Zielsystem vorhanden ist oder b) die Tabelle nicht gelöscht werden kann wenn sie noch verwendet wird.

Man könnte auch die DD02L abfragen ob die Tabelle noch vorhanden ist. Eine andere Möglichkeit sehe ich zur Absicherung des SELECT's nicht.

Viele Grüße

Norbert

Re: TRY / ENTRY beim SELECT

ralf.wenzel hat geschrieben:...ein Programm mit einem SELECT auf eine nicht bekannte Tabelle ist syntaktisch falsch und lässt sich nicht aktivieren.

Wenn die Tabelle dynamisch angesprochen wird schon.

Re: TRY / ENTRY beim SELECT

Hallo Norbert,

in der Tat eine spannende Anforderung aber der Kunde ist König. Ich würde es genauso machen wie Ralf beschrieben hat - ich glaub die Tabellen stehen in der DD02L, bin aber gerade nicht im System. Aber egal, das findest Du ja raus. Und dann eine Exception werfen damit das Ganze in das Catch Coding von Try/Endtry läuft.

Viele Grüsse
Nicola