This is a known issue, but I wouldn't have the users trying to select layouts from this layout menu anyway--especially with that many layouts. There are much more user friendly options for controlling navigation from one layout to another--including setting up your own drop down list of layouts to use for such navigation.
For More Information see: http://filemaker.custhelp.com/cgi-bin/filemaker.cfg/php/enduser/std_adp.php?p_faqid=548
This is one of many acknowledged bugs that can be found in the Known Bug List thread here in the Report an Issue section of the forum.
It can also be downloaded as a database file from: https://www.dropbox.com/s/jt09b82i0xijbu3/FMP%20Bugs.zip
Hello Phil, and thanks again for your swift answer.
I must admit that I never heard of this problem before. Funny thing is – I just checked it once more in an older version of the database –, that this problem occurred yesterday for the first time, in connection with the operations described.
There is one other weird thing I did not mention and that makes me wonder if the database may be seriously damaged: The new tables I added to the database were copies from other files – you know, I am uniting several files. During this process I made a mistake and had to delete a new table two or three times until it worked properly. I didn’t notice my mistake until I had imported the data from the original table.
Of course FM creates a layout each time a new table is added. And now that: After I had deleted the table and created a new one by the same name, FM still showed the records of the deleted table! They were not selectable etc., just “ghosts”. They only vanished when I deleted the obsolete layout.
So would you think it is secure to use this file anymore?
If You got 'zombie' scripts, cf, whatever, I would prefer to go back to the last 'good' backup and rebuild that file...
Happened here a couple of times - and we _never_ copy anything anymore from another file, the risk is to big on large solution where we can't go back to a backup of that file immediately (last and final time that this happened, we hat to wait for more tha a week until we could stop the server (resp. the file)...
I'm not really sure if this bug is solved in newer FM versions, since AFAIK it was never confirmed. Btw: I _believe_ that it occurs when copy from a local file to a server file. I never had it when copying from local to local files.