Re: GPF / Forms Builder 6 Object List Report

I can you see you are just as puzzeled as we were with our solution. I guess it should be reported to Oracle because it sure wastes a lot of development time. I am sure it is their bug. rq

Martin Angers wrote:

> 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 Mon Jan 10 2000 - 17:48:59 CET