Here's a quickie, hopefully. Trying to make some simple time-efficient data entry screens for oracle tables that have a few simple foreign key relationships. If the user violates the foreign key, PROIV will generate a SQL Error and display it in @RFUNCT. The user would then have to escape that error screen and reenter the application from the kernel prompt. Any way to make escaping the @RFUNCT screen take the user to the file browser function they were working on? The error link in the function def doesn't seem to do it.
Thanks.

Error Link Function
Started by
Guest_Serge_*
, Feb 22 2002 06:54 PM
4 replies to this topic
#3
Posted 22 February 2002 - 10:03 PM
G'Day Serge,
@RFUNCT is both a system variable and the rollback function name. Therefore it's possible to write your own fatal screen or update, and then make the following assignment @RFUNCT = ''. This means that you can control, to some extent, behaviour when a fatal error is encountered. For instance, I've written my own so that I can save the errors to a log file.
Regards
Shaun
@RFUNCT is both a system variable and the rollback function name. Therefore it's possible to write your own fatal screen or update, and then make the following assignment @RFUNCT = '
Regards
Shaun
PRO-IV free for 385 Days

#4
Posted 25 February 2002 - 09:37 AM
Maybe I'm missing something - not being so used
to programming SQL from PRO-IV - but shouldn't you
explicitely check the FK relationship and catch
the error yourself? Failing that can't the
SQL err be caught in AR-ERR logic?
to programming SQL from PRO-IV - but shouldn't you
explicitely check the FK relationship and catch
the error yourself? Failing that can't the
SQL err be caught in AR-ERR logic?
The content and views expressed in this message are those
of the poster and do not represent those of any organisation.
of the poster and do not represent those of any organisation.
#5
Guest_Serge_*
Posted 25 February 2002 - 01:59 PM
Thanks for the suggestions, I'll try them out today.
As for catching the sql error myself, certainly I should. But I just don't have time to work on these series of screens to catch every integrity constraint. If it generates a SQL error and brings the user back to the browser she was working on, that's sufficient for my purposes.
As for catching the sql error myself, certainly I should. But I just don't have time to work on these series of screens to catch every integrity constraint. If it generates a SQL error and brings the user back to the browser she was working on, that's sufficient for my purposes.
Reply to this topic

0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users