Relationship Corruption

[T-Square]

I have encountered two related problems that I can't seem to avoid regarding related files.

The first problem occurs when my client renames one of the files in a solution, which renders the relationships invalid. Of course, the client shouldn't rename the files, but there are circumstances when this is unavoidable (as when the MAC OS renames a Windows file to its 8.3 format (anyone know why???), or when a file gets corrupted, and the client recovers the file to the default "filename Recovered" format).

When the client restarts the software, Filemaker knows enough to see that the relationship is corrupt, and asks the client to locate the file, which they do.

Only problem is, that FM DOESN'T seem to change any script steps that use the relationship, and all those scripts are broken. Moreover, if we restore the filename to its original form, the scripts REMAIN broken, and must be manually restored, line by line. Suffice to say that this is not easy to manage over the phone with non-expert clients.

The second problem occurs when the client has to break out of FM in the middle of a script because the software hangs (which it does on a regular basis). In this circumstance, FM corrupts the RELATIONSHIPS, with a similar problem as listed above.

I would love to find a way to minimize or eliminate these problems; any suggestions are welcome.

[Kurt Knippel]

First, the Mac OS is not doing anything on the naming thing, Windows is actually doing this. Windows (prior to XP at least) stores the files with the 8.3 name, but stores the name that you see in the file itself and parses it out in the interface.

Second, you should not be using Recoved files in the first place, let alone having the client do this. This is one of the key reasons why Filemaker renames the file.

Lastly Filemake should not "hang" in the middle of the script.

Sadly all of this points to very sloppy development and should be addressed first and foremost from that point.

[danjacoby]

When a file is renamed or moved, and the relationship is "broken", then when you open a file that relates to it, you get a dialog box asking where the "missing" file is. Once you find it, Filemaker resets the relationship to the "new" file. Theoretically, it also resets all the scripts, value lists, etc., that call information from the related file.

My guess is that there's something the client isn't telling you (it happens to me a lot, especially with clients who are new to Filemaker). Have you actually gone in to see what they're doing?

[cjaeger]

- if 8.3 names are a problem, why not name your files accordingly.

- if you are using lengthy scripts, introduce a "save cache" step before and turn off user intervention.

-provide your clients with a clean copy and include an import step from xxx_recovered.fp5

i often point filemaker to aliases or links instead of the actual databases when updating relations, this allows fm to find the files even when names are changed. just don