Try increasing FMP's file cache size, in the preferences.
Thank you! I aleady have it set to 256, that has solved many issues in the past. I'll raise it even more and try that.
Do you know how many field were on the layout?
Hello Bruce, there are about 225 fields and 7 portals. FileMaker 12 won't let you up the cache higher than 256, which it was already and still crashed.
When you ran the file through the recover process, did it find any problems? I would be concerned that the crashes may have caused some issue with the database.
This sounds like a complex and crowded layout. Would it make sense to split it into two layouts? If the number of fields is the cause of the issue, I don't think you want to wait for a fix from them. So possibly grouping the fields and portals with some form of tab based trigger to switch layouts might return stability to the db and meet your needs.
Thank you Bruce! That's a good idea. The Recovery process didn't find any errors. I did come up with a work around. I created a new layout and copied the sub tab portal set to the blank layout and then returned to the original layout and set the tab order on the fields that needed the tab order. I then pasted the sub tab potal set back to the original layout and this worked ok.
ChrisQuinn kirjoitti 24.1.2013 kello 4.21:
We are using FileMaker Pro 12 and we have a layout with many sub-tubs and hundreds of fields.
When I read this I got a feeling of Déja vu.
I am building a solution that had lots of tabs & sub tabs and lots and lots of fields on the same layout.
At some point I thought I don't like the setup. One reason was that the solution became a bit slow to navigate and use. Too many objects on the same layout, too many portals etc.
After that I have split up the solution so that most tabs actually have their own layouts.
Using script triggers on the tabs, and building the layout names so that they corresponded to the tab names, its was pretty easy to get the navigation completely automatic.
So instead of 1 layout with about 20 tabs and sub-tabs I now have 13 layouts. Some of these still contain sub-tabs, but not so many.
All layouts do contain the tabs and subtabs, except only the functional tabs contain fields, portals and actual subtabs.
The solution became very much quicker to use and also quicker and easier to manage during development.
The navigational script is pretty easy:
Set Variable [ $TabPanel; Value:Let( [
value=Get(TriggerTargetTabPanel); co=ValueCount(value); value=GetValue(value;co)
; LeftWords(value;1) )]
Go to Object Object Name: $TabPanel
The work to split the solution up into multiple layouts was actually pretty quick. But on order to do it this way, the mega-layout was actually needed, so the work I did creating all those tabs and subtabs into one layout was not in vain. It was actually essential for the development of the solution.
But splitting into multiple layouts have made the finalizing of the solution much easier to handle. I can imagine it might help your team even more, as only one person can work on one layout at a time.
Stefan Schutt, Mouse Up, Finland
The first thing I would try is to UNGROUP all items on the layout in question.
Check out FMDiff to compare two FileMaker files and test for file corruption at <http://www.fmdiff.com>
Awesome tip, Winfried! Is it much slower with grouped objects in general or merely the number of groupings?
-- sent from my iPhone4 --
The difficulty with problems like this, FileMaker can't "fix" it, unless the "bug" is repeatable
can you make another equally dense layout crash ? perhaps in another file ?
> We're wondering if this problem is caused by the number of "set tab order" objects are limited to a certain number, and when that number is reached it crashes FileMaker Pro?
Thank you Stefan,
We do have quite a few layouts separated into other other sub-layouts and while we're not using script triggers, this may me be an elegant solution. We're not experiencing any performance issues and because this is a product we sell, one of the ways we deploy the solution is through application web services through RDP/2X and if the gotolayout script trigger has any lag, it may amplify this action so the end user might experience the transition, which we wouldn't want them to see or experience.
Thank you for the idea, we will test your suggestion.
Thanks Winified, I tried your suggestion, which was a good idea, but unfortunately it still crashes. In the testing we've done, we've definately found that field counts on a layout is an issue with "Set Tab Order" functionality. If we simply remove a group of fields, any fields, it doesn't matter, the problem is solved. I believe there is a limitation to how many fields can be on a layout so the "Set Tab Order" function won't crash FileMaker. The only other test we haven't tried is to turn off our plug-ins.
Good point Gduriak, I have navigated to less densely populated layouts and I don't experience the problem. I can consistently repeat the problem on other densely populated layouts. There is one other issue, we are using a seudo data separation model, where the data file is separated from the interface file. There are no fields or tables in the interface file. I wonder if all the relationships and related fields are an issue. I'm going to recover the data file and see if that helps.
Another thing I'm going to try is to try Set Tab Order on a Mac and see if the problem persists even on that platform.