Problem with dreport crashing

[Bruce Easton]

(inline responses - Bruce Easton, STN, Inc.)

Jeff Harrison wrote Thursday, July 31, 2008 10:36 AM:
>
> --- On Thu, 7/31/08, Fairlight <fairlite at fairlite.com> wrote:
>
> > From: Fairlight <fairlite at fairlite.com>
> > Subject: Problem with dreport crashing
> > To: "filePro Mailing List" <filepro-list at lists.celestial.com>
> > Cc: fpsupport at fptech.com
> > Date: Thursday, July 31, 2008, 10:21 AM
> > I'm really hoping I can get some advice here.
> >
> > Windows 2003 Server, fP 5.0.14DN9
> >
> > I've got a command:
> >
> > dreport cgi_control -sr 1 -u -f pk_committed_ticket_rpt -z
> > pk_committed_ticket_rpt_v
> >
> > The output processing that matches the format name is
> > currently all
> > commented out.  I was originally setting the printer there
> > as well due to
> > an error, which went away later.  Apparently I don't
> > need it.
> >
> > I'm getting the following error when I try the command
> > from the command
> > line (with environment variables set in a fashion that
> > should work
> > fine--identical to the CGI environment I'm working
> > with):
> >
> > *****
> > The instruction at 0042b9ab referenced memory at
> > 00000004oThe memory could
> > not be read from
> > *****
> >
> > The "o" after the 00000004 is in inverse.  There
> > is no other visible text,
> > even though it seems like there should be punctuation at
> > the end, or a
> > continuance or something.  That's all I get.
> >
> > That's -all- I get, and obviously fP is crashing, as no
> > report is being
> > generated.  I have a report with about 5 dummy fields that
> > are populated
> > from -v processing.
> >
> > The -v processing table is as follows:
> >
> > :BeenThere ne "0":goto sel:
> > ::declare global BeenThere(1,.0,g):
> > ::BeenThere="0";dl="0":
> > ::1=@td;2=@tm;write:
> > ::declare global
> > FLOutFile,InFile,SessID,OurHost,OurCookieHost,FLOneGate,FLAJAX,ParkRoll:
> > ::declare global City,ErrMsg,User,YearBill:
> > ::call "getvars":
> > ::declare global
> > LCCity(40,UPLOW,g),cityviofile,citymainfile,citydetailfile:
> > ::declare SDate(10,mdyy/,g),EDate(10,mdyy/,g):
> > ::declare global OGParseResult(4,*,g):
> >
> ::fo="c:/onegate/spool/pk_committed_ticket_rpt/tmp/"{getenv("ONEGA
> TE_UNIQUE_ID"){"-rpt.pcl":
> > ::printer type "hp-8000";printer file fo:
> > ::call "onegate/ogcgixml":
> > ::lookup cgi = onegate  k=(InFile)   i=A -nx:
> > cgiloop:not cgi:goto postcgi:
> > :cgi(1) ne InFile:goto postcgi:
> > :cgi(2) eq "Session":SessID=cgi(3);si=cgi(3):
> > :cgi(2) eq "edate":EDate=cgi(3):
> > :cgi(2) eq "sdate":SDate=cgi(3):
> > ::delete cgi;getnext cgi;goto cgiloop:
> > postcgi::close cgi:
> > ::call "verify_session":
> > ::LCCity=City:
> > ::call "city_lookvars":
> > :SessID eq "EXPIRED":ErrMsg="Your session
> > expired.  Please log in again.";call
> > "errpage";exit:
> > :SessID eq "NOSESSION":ErrMsg="Session
> > information invalid. ["{si{"]";call
> > "errpage";exit:
> > ::call "get_park_access":
> > :ParkRoll eq "NOACCESS":ErrMsg="You do not
> > have access to the Parking system.";call
> > "errpage";exit:
> > :ParkRoll ne "ADMIN" and ParkRoll ne
> > "MASTER" and ParkRoll ne "ADD" and
> > ParkRoll ne "CLERK":ErrMsg="You do not have
> > access to Add Tickets.";call
> > "pk_errpage";exit:
> > ::call "update_session":
> > :SDate eq "":ErrMsg="Start date field
> > blank.";call "pk_errpage";exit:
> > :EDate eq "":ErrMsg="End date field
> > blank.";call "pk_errpage";exit:
> > :EDate lt SDate:ErrMsg="End
> > date"<EDate<" is earlier than start
> > date"<SDate{".";call
> > "pk_errpage";exit:
> > ::BeenThere="1":
> > sel:dl eq "1":goto pastlk:
> > ::aa="":
> > ::lookup recs = (citymainfile)  k=aa   i=A -ng:
> > :dl ne "1":dl="1":
> > pastlk:not recs:goto donelk:
> > :recs(20) lt SDate or recs(20) gt EDate:goto skiplk:
> > ::oa=recs(1);ob=recs(14);oc=recs(20);od=recs(49);oe=recs(24);print:
> > skiplk::getnext recs;goto pastlk:
> > donelk::exit:
> >
> > All CALLs are identical to calls I made in other areas of
> > the project, so
> > none of the subsidiary tables are suspect in and of
> > themselves.  You -can-
> > CALL from -v tables, yes?
> >
> > Can anyone tell me why it's crashing on me like this?
> > Everything else
> > I've coded (within the scope of this project) is
> > working fine.  The system
> > appears to be fine.  It appears to be strictly this
> > processing that's
> > crashing it somehow, and I'm not seeing why it's
> > not being gracefully
> > handled.  This appears to be relatively straightforward,
> > yet *crash,burn*
> >
> > If this is something that was fixed in a later fP release,
> > well...upgrading
> > isn't an option, but I'd appreciate knowing that.
> > This can probably be
> > rewritten another way that won't crash.  But I'm
> > -so close- to this working
> > (I think) that I don't want to do that unless
> > absolutely necessary.  Maybe
> > I'm just doing something incorrectly out of ignorance
> > and it's a simple fix.
> > I hope.
> >
> > I could really use a fix or at least a pointer, ASAP.
> > Thanks!
> >
> > mark->
> > --
>
> I assume you mean -z processing as I don't see a -v on your
> command line.  Have you tried this withouth the -z processing to
> see if you still get an error?

Hmmm - how about some thought as to what kind of processing
might be appropriate for the code that one is doing.  I'm
having flashbacks to times where I discovered input prc code
that someone just threw into an auto table in its entirety
assuming, I guess, that it would resolve all the dummy fields
and work like magic.

But I admit - the code that appears above looks more
appropriate for an output table than a selection table.
The question is - Mark - are you really meaning to do
all those tasks in a selection table?

> How about trying this with a
> different output format?  Perhaps the output format is corrupted?
>
> I could be wrong, but - but I have a vague recollection that
> calls are not allowed in output processing.  Try commenting out
> the calls and see if you still get the error.

The 4.0 filepro manual does state that CALL is usable only from
auto and input tables.  I don't see any notes on the online manual
indicating otherwise, although I seem to remember somewhere since
a statement that call was available on all types of table.  So,
I just ran a test where I set real fields from a dreport request,
from within a called table and it worked fine, but it only set
the real fields if I used a write statement before ending
the called table.  So, to clarify, what I had was no output prc,
a selection table that did nothing but have a 'call <calledprcname>'
and inside the called prc, I set real fields that were being read
for sort/sel prc.  (the called table simply had:

::1="333":
::write:
::end:
)

The other thing I had to do to prevent a tokenization size
decifiency error from fp was to use the -tf flag on the
command line, since the called table uses the form tok size.

So CALL seems to be OK from selection prc.

>
> Jeff Harrison
> jeffaharrison at yahoo.com
>