Win 2003 Server Error Printing

Jim Asman jlasman at telus.net
Thu Jun 16 09:31:08 PDT 2005


--------------- Original Message ---------------
At 01:18P Wed Jun 15 2005, Kenneth Brody wrote:

> Quoting Jim Asman (Wed, 15 Jun 2005 09:37:49 -0700):
> [...]
> > > > > DEBUG ERROR
> > > > >    Program: \fp\dreport.exe
> > > > >     DAMAGE: After normal block (#xxxx) @ 0x00xxxxxx
> > > > >
> > > > > The problem persists whether in dreport or rreport.
> > > > >
> > > > > The filepro "generating output" screen is still up when the
> > > > > error displays. Clicking on abort clears this screen and
> > > > > you are returned to the calling menu.
> > > > >
> > > > > Has anyone else seen this?
> [...]
> 
> It might also help if you could include the actual numbers you showed
> as "xxxx", especially if they're the same each time.

            Block # 8003 0x00EC5D88
                  # 8003 0x00EC5DA0

The block # seems associated with the login and will change if I logoff
and the back on. The memory address will vary.

Later news...

The job itself will print OK in spite of the error, and by that I mean
a response to the error box is NOT necessary for the the job to complete.
The printing will proceed by itself. Of course you have to respond to
the error to get it off the screen.

I have found that if I replace the -v table with a different one that
selects the same records, NO ERROR.

My question then is what could possibly be included in selection
processing that wouldn't manifest itself until *report was ready
to exit?


Jim 
--
jlasman at telus.net                       Spectra Colour Services Ltd.
Jim Asman                               10221 144A Street
Phone: (604)584-0977                    Surrey, BC  V3R 3P7             
 Cell: (604)619-0977                    CANADA



More information about the Filepro-list mailing list