>Ed, I hate to argue with you (your knowledge far surpasses mine) but I did not get lucky with the order of records in FoxDOS. My goal was to get the last record for a particular customer. That was why I used DESC in the index command. I mean after all, if DESC was not used I would always get the FIRST record for a particular customer. Is it not logical that using DESC would then give me the LAST record for a particular customer particularly if a DESC index is an invert of a ASC index??? DESC in VFP does not act or mean the same thing as it did in DOS at least when it is used in the index command. In addition, if the index was constructed without DESC and then it was used set with DESC it would then act like the index in FoxDOS. This has got to be a bug! At the very least it is exceedingly confusing. I ran across this as I was porting some code into VFP and it took me some time to figure out what had happended - I guess that is why I am a little frustrated by this.
No, because VFP doesn't guarentee the order of equals in the index; if you want to guarentee that the last physically added record is the last record in the index for a given duplicated key, you'd best include the record number as a part of the key so that equals become distinct and orderable. Read some database theory; I'd suggest exactly the same source as I suggested for Jim - Knuth's
Sorting and Searching is one of the best sources on how various sort and selection mechanisms work at a very low level. It boils down to
if you want an index to behave so that equals fall in a particular order, you have to do something to differentiate the equal keys, so they become unique and distinct among themselves.People rely on side effects all the time. In reality, Y2K boils down to a very nasty side effect of using a compressed representation of a date; we get nailed by it because we can't guarentee differentiation of equal keys. There isn't enough information to reliably distinguish between April 1, 1900 and April 1, 2000 if you've stored the date as 'YYMMDD'; '000401' = '000401'. We have a problem because the key doesn't act in an adequate fashion to differentiate between things that are of equal key value.
IOW, you got away with using a side effect before this, and got caught. It happens in lots of places. You know how to fix it. Why not fix the problem and not make the same silly mistake again?
