Indexing Woas

[jhomer]

Greetings all

I seem to be encountering a reoccuring problem with indexing. I would like to know if anyone is experianceing similar problems.

In general our problem consists of a several oddities all relating to indexed fields. I have an inventory solution in which we capture a large bit of information regarding our material. I see reoccuring problems when personnel search for material based on a Tag #, Location code, modification date and user. all fields are set to index all. (this does not mean a searxch is done on ALL fields at once. it can be a combiniation of these fields or a single one) This has not been a problem in all previous versions of FM we have used.

With 8 we have two problems.. material is not being found when a search is conducted on those fields. This material IS entered correctly into the system. Also i have had a problem with material showing up in reports that has been moved to the archives file yet an index has been left in the actual inventory in which BLANK records are showing up in finds. This blank material has been seen to be an exact one to one with material moved to archives.

My current patch is to go into the define fields, set indexing to none. OK out of the define fields, then reenter and re-index these fields. After which all finds can be completed and are correct.

Please let me know if you have experianced any similar problems.

Thanks for your time.

[Vaughan]

Sounds like data corruption. Try save as compressed copy, then recover command. Otherwise try earlier backups.

[xochi]

My guesses:

1. Corruption. Hope it's not that!

2. I've seen weird stuff when you get invisible ASCII characters in fields. Are you perhaps cutting & pasting data from a website or emails or importing from a legacy system? You might need to batch process the inputs to clean the junk out.

3. Field Type & Language Settings -- it's possible to store text in a number field, and vice versa, and some things work but indexing won't. Check the field type, and check to see the field indexing is set properly (not Japanese, etc.)

4. Finding for symbols? One that always gets me is the @ character. If you search for an email "[email protected]" it won't be found. Are you perhaps searching for things with symbols?

[jhomer]

In addition to the compressing and recovery of the affected files is there any other course of action to take to ensure the data is cleaned. This is our first encounter with data corruption and we would like to know the best actions to take.

Again thanks for any input you may have to offer.

[xochi]

If you are sure it's corruption...

There is a widespread belief that once a file has been corrupted, the only safe thing to do is to recover the file, export all its data, and then import that data into a known good backup copy of the file (i.e. one that is known to be good before the corruption first occurred). This was probably true with filemaker 5 (6) format files. I think the jury is out on whether this is still true in filemaker 7 (8) format files.

However, even if you do follow this advice, it's not always easy to know exactly when your file first became corrupted. Sometimes its easy (e.g. if everything was working fine, then one day you had a server crash and the file was then corrupted). But sometimes you just don't know for sure.

Some advice:

1. FileMaker 8 Advanced does a better job at recovery than FM7 (I had at least one corrupted file that would actually crash FM7 when it tried to recover it. FM8A would recover it w/o crashing).

2. The file maintenance commands (compress/optimize) can sometimes help. I've had at least one file where doing Compress/Optimize BEFORE the Recovery step was the secret to recovering it.

3. After recovery, you should probably "Exercise" your file to see if it's really recovered. I'd suggest you create some dummy reports which do things such as summarizing every record in the database (to see if you have any record(s) that are unreadable). You may also want to create a script that modifies every record in the database to see if you can both read and write to every record. This will muck up your modification date, so perhaps do this on a test copy of the recovered file. Also, since corruption can affect layouts & scripts, you should test everything you can.

[Bailey Kessing]

I have also found this same behavior. Recovering does seem to solve the problem sometimes, but I have had it re-accure to the same file. Obviously, revovery alone might not always cure the underlining issue. I will have to try the compress suggestions. I would love for FM to auto do the recovery when a file can't be verified intacked and just save a backup.

[gdurniak]

Unfortunately, FileMaker has no utility to re-index, which appears to be a big issue in FM7 & 8

Although "recover" does rebuild indexes, it can also remove unexpected portions of your files, even in FM8

for more detailed info, see my post here:

http://masdevelopment.com:3455/1/57?view=print