Problem with dreport crashing

[Nancy Palmquist]

Fairlight wrote:
> 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("ONEGATE_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->
>   
Mark,

This is has been a thorn in my side for quite a while on the big LAN 
system we both support.  I found after chasing for weeks, that the issue 
was caused by a bad index.  I started double checking every posting I 
did to the file in question to make sure all the postings were using 
locked/protected lookups.

I double-checked that I did not issue a WRITE command that unlocked 
stuff and then tried to post data again. 

These steps cleared up 90% of the issues.

I changed an index used at the point of crash so it was not built on a 
date, and added another sort level to try to eliminate as many duplicate 
keys in the index as possible.  Made other changes to this index to try 
to eliminate as many records as I could that had the first two keys 
blank in the index.

Index built on: PRINTER, Date Printed, PayorID, Date of Loss and Control 
number.

A new order has only Date of Loss and Control Number with data.  Then 
when the order is processed, The Printer and PayorID is assigned, that 
is when it usually crashed.  Sometimes the Date Printed is assigned at 
the same time or it is assigned during a batch process later, which 
never caused it to crash.  What makes it crash is the write that inserts 
the PayorID into this index, on 1 out of 1,000 orders.
These fixes to the index seemed to eliminate some more issues and 
reduced the crashes to 2% or less.

Then I increased the TOK size for all TOK levels, that put me up to 
99.9% reliability. 

This seems to be comparable to the seg violation on Unix stuff, but 
after messing with the files and processing, I was able to narrow down 
the error to 1 line of code where I do a lookup to a file - locked and 
then write to one particular field using in a particular index.

To fix issues like this, I have added some sleep commands to give things 
time to write, Ken tells me that should not matter but since it fixes 
the problem, I don't believe him on this one.  Especially helps, when 
you are opening records for posting and writing to a lot of places quickly.

I think some of these steps were just trying whatever I could think of 
to make the process behave differently.  I am added the strange things 
that I always try:

1) Double check that you have not used long variable names and field 
headings and labels and selection tables and arrays with overlapping 
names.  For example:  Field Heading:    "Invoice Number", label 
"Invoice", or Selection table "Invoice" or long variable "Invoice"  Lord 
knows what filePro will do logically with this confusion. 

2) Check TOK sizes - increase if not sure.  defaults are 20000 for each 
of the three types.

3) Make sure the global edits + local edits listed do not exceed 200.  
Never, no way, no how.  This does very strange thinks.

Hope this helps.

Nancy
Nancy



-- 
Nancy Palmquist 		MOS & filePro Training Available
Virtual Software Systems	Web Based Training and Consulting	
PHONE: (412) 835-9417		   Web site:  http://www.vss3.com