Error in sort processing

[GCC Consulting]

> -----Original Message-----
> From: 
> filepro-list-bounces+gccconsulting=comcast.net at lists.celestial
> .com 
> [mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.c
> elestial.com] On Behalf Of Don Coleman
> Sent: Friday, February 16, 2007 11:16 AM
> To: 'Kenneth Brody'
> Cc: filepro-list at lists.celestial.com
> Subject: RE: Error in sort processing
> 
> 
> > -----Original Message-----
> > From: Kenneth Brody [mailto:kenbrody at bestweb.net]
> > Sent: Thursday, February 15, 2007 11:35 AM
> > To: Don Coleman
> > Cc: filepro-list at lists.celestial.com
> > Subject: Re: Error in sort processing
> > 
> > Quoting Don Coleman (Thu, 15 Feb 2007 11:20:41 -0500):
> > 
> > > I have a customer who occasionally receives the following 
> error when 
> > > running their delivery sheets (packing slips).  The 
> output format is 
> > > a report.
> > >
> > > Error line 199
> > > Edit name YESNO
> > > Field 0
> > > @RN 79503
> > 
> > What is the complete, exact error message?
> > 
> > [...]
> > >  197 -------   -   -   -   -   -   -   -   -   -   -   -  
>  -   -   -   -
> > > 41sort   If: 108 eq "Y" and 74 eq "Y"
> > >        Then: sort1=9;sort2(1,YESNO,d)=74;sort3(1,YESNO,d)=74;
> > >              
> sort4=96;sort5=52;sort6(30,ALLUP)=11{12{13;sort7=22;end
> > >  198 -------   -   -   -   -   -   -   -   -   -   -   -  
>  -   -   -   -
> > >          If: 108 eq "Y"
> > >        Then: sort1=9;sort2(1,YESNO,d)=74;sort3(1,YESNO,d)=74;
> > >              
> sort4=96;sort5=52;sort6(30,ALLUP)=11{12{13;sort7=22;end
> > >  199 -------   -   -   -   -   -   -   -   -   -   -   -  
>  -   -   -   -
> > >          If:
> > >        Then: sort1=9;sort2(1,*,d)=mid(1,"1","1");
> > >              sort3(1,*,d)=mid(1,"1","1");sort4=96;sort5=52;
> > >              sort6(30,ALLUP)=11{12{13;sort7=22;end
> > [...]
> > > Can anyone tell me why this line errors out?  If I am 
> understanding 
> > > the error correctly it seems like one of the sorts is 
> attemting to 
> > > process a field containing a 0 (zero) where the edit is 
> defined as 
> > > YESNO.  I guess the two likely candidates are sort2 and sort3 
> > > because the both contain a 0 (zero) but the field is 
> defined as edit = *.
> > > I'm at a loss (again!).
> > 
> > --
> > KenBrody at BestWeb dot net        spamtrap: 
> <g8ymh8uf001 at sneakemail.com>
> > http://www.hvcomputer.com
> > http://www.fileProPlus.com
> 
> 
> Ken:
> 
> Don't know if you have any thoughts on this yet but I can 
> shed a little additional light on the situation.  Orders are 
> received into filePro from two different sources.  An 
> application called QS/1 exports data to a text file every 
> four minutes and a filePro ascii import process imports that 
> data.  This client has begun a transition process to replace 
> the QS/1 application with another application (CIPS) that 
> sends fP data via a socket connection.  If all orders are run 
> on the same application per day they do not experience the 
> error.  However, if one or more orders is entered
> (mis-stakenly) into the QS/1 application while the remainder 
> of their orders are entered into the CIPS (new application) 
> that error will occur.
> 
> What has me confused is that both alien app's have the data 
> they provide imported into the same exact fP file.  It is not 
> a mirror file.  If an edit test was failing wouldn't that 
> data be disregarded and the field be blank, hence not causing 
> an edit failed error message during an *report process?
> 
> Finally, could the record being reported in the fP error 
> message not be the record actually causing the problem but be 
> either the order just before or just after this record in the 
> sort process?  
> 
> Any suggestions appreciated.
> 
> 
> 
> Don Coleman
> Donald G. Coleman, Consultant
> 402 Andrew Circle
> Indiana, PA 15701
> dcoleman at dgcreact.com
> (724) 349-6302

Don,

What I have done in a similar situation where I didn't want to run the
debugger, was to put up show statements with the order #, record #, and the
field that the edit is failing on.  This allow me to see what is happening.
If it is always failing on the same record #, put :@rn="nnn":show "@"<field
# before the line where the process fails and display the  problem field.
This will stop the processing at this point until you press <enter>.  You
might be able to spot the problem.

Of course, you could, if running dreport or dclerk, replace the Show "@"
with debug on and walk through the processing from that point in the record
giving you problems.

Richard Kreiss
GCC Consulting