Dbase III Index File PLEASE HELP

[Peterthepooh]

Hello all, I'm desktop user for the dbase III program and needs your help please.

I can get into the program and retrive employee info, but when I enter time into it, only on the second line I get Line 113 GET_TIM error 19 (error 19 I believe it's Index file does not match database). How do I fix this problem please?

The problem occured when I entered employee time before and the system froze so I had to reboot.

THanks,

Peter

 

[1oldfoxman]

Are you just the user of an application, or do you have the dBaseIII programming environment available to you? If you do, and it is really only a corrupted index file, and assuming you know the data file name, index file name, index fields, and index orders (if any):

USE MyTable
INDEX ON MyField TO MyIndexFile

It almost sounds to me like a changed field name in the database, renamed index file, or someone opening an index associated with a similarly structured database (almost the same). These situations might need slightly different fixes.

HTH
Dennis

 

[Peterthepooh]

1oldfoxman,

Thanks for your reply, I'm just a user so I have no knowledge how database index files work. But I am proficient in windows so if there's any way you can help me I would certainly appreciate it. The problem is I don't know which database file is corrupted. I notice after I use the dbase programs several (5-8) different database files are updated regularly. The only error message I got is the one I listed above (error 19), and it ONLY happens when I am trying to update the timesheet information. EVERYTHING else in the program works. If the error I'm getting is dbase index file related, how exactly do I go about fixing or comparing them? If you or anyone else can help me out that would be great.

Thanks,

Peter

 

[1oldfoxman]

Peter, find the database (.dbf) and index (.ndx) files on your hard drive for your application. Try to figure out which ones are the problem (it appears that there may be an index file named get_tim.ndx, hopefully it's apparent to you which database this is associated with based on names or your experience with the application). Also locate the file dbase.exe. Note where these files are located.

dbase.exe is the dbase interactive environment, which I believe you will need to rectify this problem. When you've got that info, come on back and we'll work on the commands.

dennis

 

[tviman]

Peter,

I tend to agree with you that it's the index file(s) that are corrupted. If the system froze while you were entering data, that will corrupt any open index files 99.99999% of the time. You might want to check to see if your application has a "maintenance" menu that will rebuild the indexes. If not, 1oldfoxman's solution is the best bet.

There's always a better way. The fun is trying to find it!

 

[Peterthepooh]

TVIMAN,

Thanks for your help there is a maintenance menu and one of the option is index files, I ran it and everything seems to work now. However, I noticed the file size has shrunk quite a bit, going from 13 megs to about 8 megs, is this normal? I'm worried that some data may be lost.
Thanks,

Peter

 

[tviman]

Peter,

The index file(s) are built from the data in the DBF files. It's not uncommon to have file sizes change after a reindex. Unless you have a way of viewing/printing the files, and you know what's supposed to be there, then there's little you can do to check for lost/corrupted data. It's doubtful that you lost any data due to the way that databases are read and written to. Generally, you'll lose any data that you were entering before you hit the ENTER key at the time of a freeze-up but rarely will it affect what has already been written to the files.

If the application works as it should, I wouldn't be too concerned. However, this is a good reason why you should be doing regular data backups!

There's always a better way. The fun is trying to find it!

 

[dbMark]

Index files will grow in size over time. Whenever the indexed fields in the tables change, the index appends a new reference into its file, making it slightly larger in size each time. Do that a few dozen or hundreds of times a day for a few months or years and, yes, your indexes will be larger than need be. Reindexing (or selecting the "maintenance" option if a smart programmer made one available within the program) will definitely shrink the size of the index files. Also, the programmer may have also designed the routines to "pack" all the tables as well, getting rid of deleted records, which would shrink the size of tables too.

Like with cars, maintenance is not only done when the system crashes and burns, it can also be scheduled periodically to minimize small problems that may not otherwise be noticed until they're big nasty problems.

If you want to be cautious, archive your data before running the maintenance routine.