Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!usenet
From: tmkk@uiuc.edu (K. Khan)
Newsgroups: comp.databases
Subject: Clipper 5.01 bugs
Message-ID: <1991May14.170431.1509@ux1.cso.uiuc.edu>
Date: 14 May 91 17:04:31 GMT
References: <1991May7.235644.28744@gmuvax2.gmu.edu>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 77


In article <1991May7.235644.28744@gmuvax2.gmu.edu> mhovan@gmuvax2.gmu.edu (Mike Hovan) writes:
>
>	Well I recieved 5.01 yesterday, installed today, and almost
>threw it out the window tonight.

I know precisely what you mean!

>	Anybody know what the following error means:
>
>
>	 (0)  Unrecoverable error 668 : Eval Stack Fault
>	run-time error R6001
>	-  null pointer assignment

Nope, I just came here to gripe! ;-)

>	Doesn't look good, I know a MSC error when I see one.  You know
>this is the 3rd revision of the Clipper product I have worked with  
>(S87, 5.0, 5.01) in the last 3 years, and as far as I am concerned this
>thing is still in alpha test mode.

That's for sure.
  
>	The error happens before getting into any of my code (the first line
>of code is a DISPOUT("MADE IT") and that never gets executed).  The 
>particular project is about 7000 lines of code (re)written from scratch
>when 5.0 came out.  The program has no warnings under the 5.0 compiler.

It's pretty pathetic when code that compiles and runs fine under 5.0
breaks when compiled under 5.01, an alleged bug FIX. Here's my horror
story (hit 'n' now if not interested):

After installing the Clipper "upgrade," I recompiled my current project
(not sure how big, but there are a couple dozen program files, maybe
20,000 lines of code). The first thing I noticed was that the size of
the executable grew (it's now over 500K) as well as the amount of memory
needed to run as indicated by .PLink. The worst part, however, is that a
report routine that works fine under 5.0 locks up under 5.01. It opens
two databases, steps through one while SEEKing associated records in the
other. After each seek, I check to see if the record was found().
Somewhere during the call to found() the program disappears into the bit
bucket (that found() is the location of the bug was verified both with
debugging print statements as well as the Clipper debugger). Commenting
out the line containing the call to found() avoids the lockup.

The really bizarre part is that the problem ONLY occurs when I have
output redirected to the printer using the SET PRINTER command! I can
generate the report and send it to the screen, or to a disk file, with
no problems whatsoever. It only locks up when output is going to the
printer. This NEVER happened under 5.0.

The workaround is to use recno() and reccount() instead of found(),
thusly:

replace

    if (!found())...

with

    if (recno() > reccount())...

Since I wasted quite some time figuring this one out, I haven't had a
chance to run across any of the other new Clipper bugs yet... :-(

Oh, the Norton Guides won't run on my PS/2 Model 70 with 2Mb of RAM and
QEMM, either, and since cheapskate Nantucket isn't sending out any
printed versions of the new Clipper documentation, I am forced to
disable QEMM and reboot my machine whenever I need to look something up
in the documentation. :-( :-(

I suspect that we're about to see a large-scale exodus of former Clipper
users to other products. Nantucket blew it once with the first release
of 5.0, and now it appears that they have blown it again.

I hear Fox is coming out with a new compiler for FoxPro...