Is importing a script supposed to break the link to any attached objects?

[Rockxyzzy]

Hi!

I've just made a ton of changes to the scripts in a development version of my file (one with test records that I've entered) and I'm ready to import the modified scripts into the live version of the file (the version without any test/debug records inserted).

When I import a script, every button object in the entire database loses its connection to the imported script. Is this a limitation on importing scripts?!?!?!? If so, that's a pretty significant failure, if you ask me. It seems amazingly bad for FMP to be unable to retain a link to a button object for a script that's replaced with an imported one.

If I'm missing something here, please tell me how to replace an existing script with an imported one and not break links to any button objects that link to the replaced script.

(For some reason, my signature is showing old data. I'm running 8.5 Advanced under Mac OSX 10.4.10)

Edited October 13, 2007 by Guest

[Rockxyzzy]

I think I found a workaround by opening each script in the source file, copying all the steps, opening the same script in the destination file, deleting all the script steps, and finally, pasting the script steps from the source file into the destination file.

This seems to be the only way to replace a script without breaking links.

Please tell me there's an easier way.

[Ender]

Ho Rocky,

Yeah, it takes a little trial and error to get used to how FileMaker links elements internally. For most things, they are linked via an internal ID number (that we don't see or have any control over). The advantage of this is you can change the names of layouts, scripts, fields, relationships, value lists, and almost everything stays linked together quite nicely*, even if they are in different files.

When you import a script, even if it's a revision of an existing script, FileMaker treats it as a new script, and gives it a new internal ID. This of course means the other elements know nothing about it, and you have to reset any references to it.

My suggestion for revising complex scripts is to either do so in your offline version and (1. Redo the script steps in the new version (use Copy & Paste if you have FMP Advanced), or (2. Import the data from the production database into the revised copy. Or, do the work in the production database in a copy of the script, making sure not to run the script in real production records. Then when it's all debugged and approved, change the references on the layouts (or other scripts) to point to the new version.

*Exceptions being things that are tied to the names of value lists, fields, layouts, or scripts. i.e. ValueListItems(), Go to Layout[by name], and any conditions you have referring to get(scriptname), get(layoutname), etc.

[Edit] Another oddball is stored Import[] mapping. Import mapping is done by the relative order of the fields from their creation order. You can change the names of fields in source or destination file, but if you delete a field, it will shift the import mapping for fields that were created after that one. This behavior is easy to forget, and can cause lots of mischief.

Edited October 13, 2007 by Guest

[Rockxyzzy]

Thanks for clearing it up. It makes sense the each script would have a unique identifier to prevent problems.