>>> getting a little long winded!
>>>
>>>Silly, but not so silly...
>>>
>>>I went looking into the table for said records, to see if they were deleted in error. Unfortunately, no... They were not there..
>>>
>>>thanks for all of your ideas,
>>>
>>>mike
>>They were not there ? Wasn't it a cursor ? You looked at workordr I guess. But I meant Jobstoprint. Deleted there, set deleted is on while scan...endscan but set deleted off in reporting (report use Jobstoprint or workordr?). And no code in between ?
>>Cetin
>
>Once the scan/endscan loop is done, this is the rest of the code.
>
>sele JOBSTOPRINT
>** run report
>report form wk_ordr2 to print noconsole
>return
>
>That's it., All she wrote...
>
>This all happens in code, no user intervention, except to pick the parameters for the report.
>
>Since I get all of the numbers, i.e. no missing ones, the numbers must be in the jobstoprint cursor.
>
>As stated previously, they are not appearing in the workordr table. That is the crux of the problem.
>
>Mike
Mike,
I could produce something similar with playing "set deleted". Report dataenvironment used "set deleted off" and scan..endscan "set deleted on". I never saw "insert into" fail yet (except code error). So there should be something else skipping in recs. The most suspect place is scan..endscan routine. If it's not "set deleted" and there is no relation in effect only inc routine would be left to check for me. Any table operation there ?
Cetin