Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!bsu-cs!neubauer
From: neubauer@bsu-cs.UUCP (Paul Neubauer)
Newsgroups: comp.databases
Subject: Re: dBASE III+ bug?
Message-ID: <6185@bsu-cs.UUCP>
Date: 17 Mar 89 16:38:35 GMT
References: <6056@bsu-cs.UUCP> <21458@agate.BERKELEY.EDU> <407@uncmed.med.unc.edu>
Reply-To: neubauer@bsu-cs.UUCP (Paul Neubauer)
Distribution: na
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 56

In article <407@uncmed.med.unc.edu> danielg@uncmed.med.unc.edu (Daniel Gene Sinclair) writes:
>>#*Here is a question for anyone out there more knowledgeable than I about
>>#*dBASE.  I am doing an application involving several tables (.DBF files)
>>#*dBase...
>>#*I then index on
>>#*             	request_no+str(item_no)
>
>etc... etc... 
>
>  [and the idexes are not updated properly when I append blank]
>  
>Then another guy writes...
>>Check your manual on this, but I suspect you may be having a
>>problem with STR defaults because you don't specify the length
>>or number of decimal points of your output string, such
>>as STR(item_no,5,0). So if you expect to get all digits, it's
>>possible that there are spaces and periods embedded which
>>interfere with indexing as you intend.
>>
>>Steve Goldfield
>I am only a novice user but here's some suggestions.  I think the Steve is
>right.  With numeric feilds, if you don't specify the string length,
>    index on request_no+LTRIM(str(item_no3,1))

I was the person who posted the original question.  I have already thanked
several people who have sent email and I would like to thank the answering
posters here.  The answer, as I have managed to (mis?)understand it, does
appear to have something to do with variable (or at least unspecified)
length indexing expressions.  I am not sure I understand it much better than
that, but since I am not trying to write a bug-for-bug compatible compiler
or the like, I guess I don't really have to.  

I would like to mention, for Daniel and Steve, though, that the problem
really is with whether dBASE III+ _maintains_ the indexing properly during
the append and edit operation, not with whether the expression sorts
correctly.  Note that the space character (leading blanks in the string)
precedes all of the digits (and incidentally all other printables) in the
ASCII collating sequence.  Thus, the string "anything 9" correctly precedes
and sorts ahead of "anything10" as long as the strings 'anything' are
identical (including internal spaces).  Therefore, strings with some
sequence of code characters followed by STR'ed representations of numbers
(even in their default lengths with lots of leading blanks) sort correctly
by the numerical values, and REINDEX produces a correct index.  The problem
is that somewhere in the APPEND BLANK and EDIT process dBASE forgets to keep
track of the fact that the index needs to be updated when the index is on
	 request_no+LTRIM(str(item_no))
but not when it is on
	 request_no+LTRIM(str(item_no,3))
I can, and by now have, work around this, but I can hardly see how to
consider it anything other than a bug.

Thanks again all.

-- 
Paul Neubauer         neubauer@bsu-cs.bsu.edu        neubauer@bsu-cs.UUCP
                      <backbones>!{iuvax,pur-ee}!bsu-cs!neubauer