Is there a difference, any difference in the world, between editing a record by clicking on modifiable fields and editing a record by running a script that uses nothing more than the "Open Record/Request" command?

I have a problem with FileMaker crashing when I commit records in some of my layouts. It freezes, and if I force quit it and restore the file, I find that it has added thousands of empty records to the tables. But the thing is that this only happens if the way I first got into the record is when I have used the script. I reduced the script to one line, "Open Record/Request", and still the problem happens. It does not happen when I simply click in a modifiable field and then commit the record.

I am getting pretty tired of restoring files and mass-deleting empty records.

Is there a script trigger at work here?

The empty records suggest there is a script trigger defined to create a new record and is acting recursively.

Selecting the script from the menu does the same thing.

Incidentally, there is a global field in the table that displays on the layout, and whenever I commit the record after having used the script to open it, it looks like the global field is selected while the program sits there frozen. Could that have anything to do with it? It still does not explain why the single-line script is different from simply modifying the record.

Edit: No, deleting the global field from both the layout and the database did not help.

Edited August 13, 200916 yr by Guest

Hold on; you were right. There actually is a script trigger that activates when a record is committed in this layout, and turning it off fixes the problem. I just have to figure out why the problem only happens when the record is opened a certain way.

Fixing some problems in the script seem to have solved the problem. Thanks for your help. Still, I do not understand why opening the record one way is different from opening it another way.

Script Triggers only happen under certain situations - please check out the help system.

... if I force quit it and restore the file, I find that it has added thousands of empty records to the tables

It sound as though the interaction with the script trigger was causing the creation of new records... it appeared frozen because it was in an infinite loop.

Ummmm, you know that putting restored files into production is not good practice...

Is there something wrong with restored files? I have been testing mine and they do not seem to have many problems, although sometimes things will be missing and I have to add them from previous versions of my database.

Take heed Timothy.

If you have things missing from a recovered file then it is almost certainly damaged - do not proceed with even a suspect file.

Make a copy of your file(s) before testing unknown areas, and revert to the backup if your tests fail.

I am doing more backups now so that I do not have to use recovered file. The file I am currently using is based on a file that was once recovered, but it seems to be fine. Thanks for the advice.