Debug Assertion Failed!

[Chris Sellitto]

> -----Original Message-----
> From: Kenneth Brody [mailto:kenbrody at spamcop.net]
> Sent: Friday, March 15, 2013 11:18 AM
> To: Chris Sellitto
> Cc: filepro-list at lists.celestial.com
> Subject: Re: Debug Assertion Failed!
> 
> On 3/15/2013 10:21 AM, Chris Sellitto wrote:
> > filePro(r) 5.7.03
> > Windows Server 2008, Windows 7/XP workstations
> >
> > All,
> >
> > We recently upgraded to 5.7.03 from 5.0.14. Everything has been going
> > well  so far. Yesterday several of our users reported an error that I
> > have not seen before. It reads exactly as follows...
> >
> > __________________________________________________________
> > |Microsoft Visual C++ Debug Library
> > |_________________________________________________________
> > |Debug Assertion Failed!
> > |
> > |Program: g:\fp\dclerk.exe
> > |File: f:\dd\vctools\crt_bld\self_x86\crt\src\isctype.c
> > |Line: 56
> > |
> > |Expression: (unsigned)(c + 1) <= 256
> > |
> > |For information on how your program can cause an assertion Failure,
> > |see the Visual C++ documentation on asserts.
> > |
> > |(Press Retry to debug the application)
> > |
> > |____________________________________________________________
> > |               Abort      Retry      Ignore
> > -------------------------------------------------------------
> >
> > I can consistently recreate this error.  It is happening to a
> > particular
> [...]
> 
> 
> Since you can recreate it on demand, contact fpsupport and arrange to
> send them files.
> 
> --
> Kenneth Brody

Ok Ken, I will do that.  However, we did narrow it down to a line of code.

It is as follows

declare local lu_key(10,*)
  -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
                                        'get Batch shipped date
lu_key=CustNo&BatchNo
  -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -

lookup bats = batsetup@  k=(lu_key)   i=A -nx		<---------- THIS IS THE OFFENDING LINE

Also when we navigate to the next record that does the same lookup using the same data in LU_KEY,
it works just fine (meaning we do not get the error described above).  This line is in a called
processing table that is called from auto processing.  

When we try the same program, using the old (5.0.14) version there is no problem.

Thank you
Chris