I am reworking an old FP 1.X app for a friend of mine who's small company has used this very reliable, but ever more obsolete, DOS based app to manage the company's manufacturing and accounting data.

My friend has become used to the stand-alone paradigm where tables are routinely sorted, packed, rebuilt and reindexed on an "as needed" basis with very little trust put into "virtual" elimination of deleted records and automatic reindexing as records are appended, deleted and edited.

But...the move to VFP has been motivated by the need to delegate data entry and modification tasks to non-expert users who must work in a shared access environment. So, although maintenance activities that require exclusive access can still be done fairly regularly (during "night" hours) a level of trust has to be established that VFP's "virtual" methods for keeping records indexed and deleted will work reliably during the course of each work day as company data is modified.

I know that in theory VFP should maintain the integrity of its virtually "sorted" enviroment. But although I'm very new to DB development, I've been programming long enough to have developed a natural paranoia with regard to how well complex software tools conform to theory. So it's a little hard for me to tell my friend, "no problem...it says right here in the documentation that everything will be copacetic".

So my questions go to anyone out there who rely on VFP for reasonably complex/dynamic datasets upon which a business relies.

How often do you routinely maintain your data by physically rebuilding it?

What operational factors govern your choice of how often you perform such maintenance?

Are there any well-known pitfalls that victimize novices vis-a-vis database maintenance when converting from a stand-alone to a shared access envirnoment.

It seemed to me like this would be a good topic for a knowledge base article, but I couldn't find one. A pointer to a technical article that addresses these issues would really be helpful.