Re: GPF / Forms Builder 6 Object List Report

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 Tue Jan 04 2000 - 21:03:49 CET