Clipper 5.03 multiple index entries 2

[jcarls]

Has anyone ever run across a situation in which an index develops multiple identical entries as records are added? I have a loop that steps through a table and then either creates a new record in another table if the key fields don't exist, or updates a date-related sequence of fields (month01, month02, etc.) if the record already exists. When I looked at this in DBU, the resulting table looks fine, yet activating the index that was active when it was built shows multiple identical records (with the same recno() value). The index is deleted prior to the start of the loop, so I can't think of a reason why this might occur. Any ideas? Thanks!

J. Carls

 

[TonHu]

It depends largely on the RDD used, and also the size and number of records in the dbf. Please report.

Are you using Clipper 5.03, or 5.3?, 'cause I don't recognize the 5.03 version... so I assume it's 5.3. if so, be sure to install all updates and fixes available from CA.

HTH
TonHu

 

[jcarls]

Sorry, I completely messed up the version reference: It's 5.2e. I'm using it via a pcAnywhere window into the legacy PC on which the software was developed, so it seems unlikely that it's a change in the environment. I seem to have "cured" it by changing my ending code from

SELECT 'alias'
USE

to

CLOSE 'alias'

and then added a COMMIT after that. Supposedly (because I added the code to do it) both the dbf and the ntx were being deleted each time prior to running the function, but what I got was an index with an additional set of pointers each time I ran it instead (so that, when I selected the index, I would see two then three then four then five instances of the same record number). Very strange.

JC

 

[TonHu]

Ah, so you're using the DBFNTX RDD, and that is known to be rather buggy :-( I've written about that on several occasions in this forum.
Committing, Closing and reopening the files would be a cure, but if it has to happen often will become a perfomance issue.

Switching to DBFCDX (or xHarbour altogether...) would solve most of the issues, and also helps if performance is already an issue.

HTH
TonHu

 

[JCreamerII]

JC,

Were the dups only showing with the index open, and not actually in the DBF. If so it is the index, erase the old index and execute an INDEX ON to setup the index again. If you were doing the INDEX ON without erasing the existing index that can cause the problem you saw. The old index was corrupt and that was causing the problem to reoccur. Strange to see this with the old index being erased. Sounds like a windows thing, how many records were added before the problem was apparent. Has the version of Windows been upgraded lately?

Jim C.

 

[jcarls]

>The old index was corrupt and that was causing the problem to reoccur. Strange to see this with the old index being erased. <

Yes, indeed. From your comments, it looks as if the old index was not being erased properly.

I looked through other parts of my old code and noticed that I was using ferase() with arrays of file names, whereas here I just had two files and used ERASE instead (because that's what I use in VFP and had forgotten the Clipper options). In any case, it seems to be working now.

As far as Windows versions go, the development env is on a Windows 95 system, with the exe moved to another 95 acting as a server disk and run from a 98 workstation (these are all from the original development era). When I'm done, it will replace the current version (from the same dev env) that is running on XP systems. I'm a little uncertain that the Windows version is the direct problem, though. It's more likely that my fading memory of how I did things in the first place is leading me into untried approaches.

My biggest problem in going back to this is that I'm adapting some murky statistics code written by someone who was not enthusiastic about using meaningful variable names and I can't get the debugger to run. I am not sure, other than the prerequisite of using /B, how to get it to work anymore.

JC

 

[JCreamerII]

jcarls,

I seen weird things happen when the underlying OS gets updated. Usually forcing an extra COMMIT or two to clear it up. But the ghost images of a record is almost always a corrupt index. I always test for the old index with an IF FILE() and then ERASE "FILENAME" if found.

Jim C.