Re: GPF / Forms Builder 6 Object List Report

[Quoted] 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 - 18:39:58 CET