Reindex hangs in large dos app 1

[henrym56]

We have a large fox pro 2.5b app in which the index process "hangs" (sometimes indefinitely) until the user presses a key (spacebar or Enter). Then it proceeds until the next endless pause.
This seems to happen more in tables that have a large number of index tags. Many of the tables have both CDX and NDX's. (It is an old application)
We have tried everything we know of and this still happens. The same application has worked well for years and it is now failing. We are working frantically to get the app re-written in VFP but for now our clients still must reindex in the DOS app.
Is the answer in the memory settings in config.fp? Is it something in config.nt? Could Tame be an issue?
TIA,
Henry

 

[rgbean]

Henry,
You didn't say what the OS of the user's station is, or what the File Sever's OS is. Do they use any screensaver? (on either system) How busy is the network? What network protocol(s) are you using?

Rick


Rick

 

[Philmap]

Henry,

We do not have such a problem with 2.5b and we have very large databases. Used on DOS 5 up to Windows XP for years.

Did you tried erasing the index file before reindexing. This is very very efficient. We always do that.

The code would have to be written like this;
CLOSE ALL
ERASE CLT.CDX
INDEX ON CODE TAG CODE
INDEX ON NAME TAG NAME
INDEX ON PHONE TAG HOMEPHON

... and so on. This produces a much cleaner index file since it doesn't have to take the actual one in consideration, it rebuilds a brand new one.

More memory will just reindex faster since all the reindexing will be performed in memory. If you do not use enough memory, Foxpro will use lot of disk space - do you have enough? This is very important.

Did you tried the 32 bit version. That would be easy to try.

Tables that have a large number of index tags: how many ?

Tables are big?

VFP will just allocate memory dinamically but I would doubt very much that the problem cannot be solved with Foxpro 2.5b

 

[severach]

Using ERASE CLT.CDX will generate an error when CLT.DBF is opened the next time. I find that DELETE TAG ALL accomplishes the same thing without any errors.