Re: GPF / Forms Builder 6 Object List Report

OK, here's what I found (please, don't ask me WHY!!!!):

Object List Report doesn't like cursor%NOTFOUND statements (sometimes, usually in big TRIGGERs or Program Units). What I did (I swear it's true) is change the cursor%NOTFOUND statements to the equivalent NOT ( cursor%FOUND) and it worked fine!!! I just changed all NOTFOUND by FOUND in all the forms that had the problem, and now they all work fine.

Beats me...
Martin Angers
Larochelle Gratton
mangers_at_larochelle-gratton.com

Robin Quasebarth a écrit dans le message <38725225.38495B4C_at_digitalpoint.com>...
>Well, let me know what you come up with that fixes your problem. For some
>reason, when we modified all the forms written by this one person in that
>particular style, the Object List Report worked. We all kinda scratched
our
>heads wondering what exactly caused the blow up. rq
>
>Martin Angers wrote:
>
>> However, I'm a little bit concerned about putting the %FOUND right after
the
>> OPEN statement because in the Forms Builder documentation, it is said
that
>> before the first FETCH, %FOUND and %NOTFOUND returns NULL, so it is
useless.
>> I haven't tried it, so maybe the documentation is wrong about this...
>>
>> I'm currently looking in a small form as to how to resolve this in
another
>> way, but your solution is working as far as Object List Report is
concerned.
>>
>> Martin Angers
>> Larochelle Gratton
>> mangers_at_larochelle-gratton.com
>>
>> Robin Quasebarth a écrit dans le message
>> <386E644D.1597A74E_at_digitalpoint.com>...
>> >OK, I found it. We were having a problem with a couple of forms blowing
up
>> at
>> >running an Object List Report. The only thing I did was isolate some
>> triggers
>> >that were causing problems and re-worded the PL/SQL and then they
worked.
>> Many
>> >triggers were different yet written in the same style then changed to
the
>> 'GOOD'
>> >style. Not sure the actual WHY Forms would blow up on such code when
the
>> form
>> >runs and performs properly...BUT this was a fix to many from that point
>> on.
>> >Check lines at and after "open esi_cursor." It was pretty bizzare and a
>> long
>> >story on how I figured it out. rq
>> >
>> >-- the BAD code:
>> >chk_rfield;
>> >check_failure;
>> >--
>> >declare
>> > cursor esi_cursor is
>> > select des, div
>> > from pts_glmdiv
>> > where div = :SC1.GLDIV
>> > and co = :SC1.ENTNO ;
>> >begin
>> > if (:sc1.gldiv is null ) then
>> > bell ;
>> > disp_msg('ERROR!! Division must be entered, press [List].');
>> > raise form_trigger_failure ;
>> > end if ;
>> > open esi_cursor ;
>> > fetch esi_cursor into :SC1.TDIVDESC, :global.gldiv ;
>> > if esi_cursor%notfound then
>> > bell;
>> > disp_msg( 'ERROR!! Division not on file.' ) ;
>> > raise form_trigger_failure ;
>> > end if ;
>> >end ;
>> >-------------------------
>> >--replaced with the GOOD code:
>> >chk_rfield;
>> >check_failure;
>> >--
>> >declare
>> > cursor esi_cursor is
>> > select des, div
>> > from pts_glmdiv
>> > where div = :SC1.GLDIV
>> > and co = :SC1.ENTNO ;
>> >begin
>> > if (:sc1.gldiv is null ) then
>> > bell ;
>> > disp_msg('ERROR!! Division must be entered, press [List].');
>> > raise form_trigger_failure ;
>> > end if ;
>> > open esi_cursor ;
>> > if ( esi_cur%found ) then
>> > fetch esi_cursor into :SC1.TDIVDESC, :global.gldiv ;
>> > close ESI_cur;
>> > end if;
>> > if esi_cursor%notfound then
>> > bell;
>> > disp_msg( 'ERROR!! Division not on file.' ) ;
>> > raise form_trigger_failure ;
>> > close ESI_cur;
>> > end if ;
>> >end ;
>> >
>> >
>> >Martin Angers wrote:
>> >
>> >> We are using the Object List Report feature of Forms Builder 6.0.5 on
>> >> Windows NT 4 to generate documentation of forms and menus and then we
>> insert
>> >> this information in a database (we built a tool that parses the text
file
>> to
>> >> gather the information we want). It works fine for most of the
over-200
>> >> forms of the application, but for some 35 of them, Forms Builder
>> generates a
>> >> GPF when we execute the Object List Report (formerly Forms Doc). I
heard
>> >> about a workaround saying to put the long TRIGGER code into a Program
>> Unit,
>> >> but for some of these forms, the GPF is caused by long Program Units
>> code...
>> >>
>> >> Is there a patch available or is there a workaround to this problem
>> (other
>> >> than moving the code to a program unit)?
>> >>
>> >> Thanks,
>> >> --
>> >> Martin Angers
>> >> Larochelle Gratton
>> >> mangers_at_larochelle-gratton.com
>> >
>
Received on Thu Jan 06 2000 - 21:32:18 CET