guten morgen,
@frank

mit der dummy tabelle ist nicht schlecht.ich kombiniere sowas zusätzlich mit einem anderen weg.

zum einen schreibe ich alle funktionen und prozeduren gebündelt in diverse packages,so hat man alles schön geordnet beieinander.

das hat den vorteil, dass ich apex gar nicht benötige ,sondern die funktion/prozedur
richtig gut testen kann, z.b. mit plsql-developer (nicht zu verwechseln mit sql-developer).

erst wenn der test erfolgreich ist binde ich die prozedur in einen seitenprozess ein.

hier mal ein beispiel:
-----------------------------------------------------------------------
datenbank prozedur:

[pastebin.com]

--------------------------------------------------------------------------------

in apex dann der dazu passende seitenprozess:


CM_MEAT.INS_TEMP4PRINT_NULL(:P102_ART,:P102_ABGEBER_ID,
TO_DATE('01.'||SUBSTR(:P102_DATUM,4,7),'DD.MM.YYYY'),
TO_DATE(:P102_AUSZAHLDATUM,'DD.MM.YYYY'),
:P102_X_BEM_4_INSTEMP,
:P102_X_QUITT_ORT,
:P102_BETRAG,
:P102_CHECK);


ich teile mir das quasi auf.die funktion/prozedur selber,und dann halt apex.
meine prozeduren usw kennen auch keine apex-elemente. die werden ganz zum schluss eben schnell im seitenprozess eingebunden ,siehe beispiel.

vorteil ist eben, dass man den code getrennt von apex halten kann (wichtig bei der fehlersuche) und gleichzeitig die volle power vom bearbeitungwerkzeug nutzen kann!

g/c







1 mal bearbeitet. Zuletzt am .