I have a user who has twice now had their indices clobbered in the last month (no other user has ever experienced this problem in 7 years of deployment. I have no idea what could be causing it to happen).

I am able to fix their database by simply importing the data into a clone of the database.

But that requires them sending me the database, doing the import, and redistributing it. And if I'm not sitting by the phone, they can experience significant downtime.

Is there some strategy/function/script I can implement so that they can cause the indices to be rebuilt from their user interface, or am I stuck with getting involved should it happen again? I don't want them having to get involved with copying/renaming/etc. file activity with clones at their site.

I restrict all my users' interface to the database (runtime) through scripts. Most users are relatively computer illiterate and probably couldn't do file manipulation without me involved anyway.

Thanks in advance.

possibly a script to export all data as text, to FileMaker's Temp Folder (or a duplicate table), delete all, then import back

a simple feature request would be a menu choice to "re-index" a field, from the client

greg

I've tried something similar:

saving the data and then importing it back in.

I deleted the original records AFTER importing back in, not before.

That did not work.

Does it make a difference if the indices are corrupt as to whether I delete before or after the import?

I think that this is where you come in. Currently FMP does not have a function to isolate reindexing of the indexed fields without manually doing.

You can export the data as text or mer files and then import them into a cloned copy if you wish.

it would be best to try "delete all" first, then import.

however, you bring up an interesting point. If the Index is corrupt, and points to records that don't exist, deleting all records will probably not delete all index entries

you may find that you have to save as clone, then import. Or, turn indexing off, then on