"Saving a layout" means you are returning to browse mode from layout mode and saving your changes? On a file that others are actively using?
well... yes. I noticed that if a second user starts modifying layouts (not necessarily at the same time), then the slow down is even greater and continues until that user has closed the file (even if he doesn't modify layouts anymore)
Thank you for your post.
Is it possible one of the users is modifying a record in the layout? Or, has the cursor active in a field on the layout?
If not, then it is possible the layout is damaged. Try recreating (not duplicating) the original layout. Does the issue still occur? Is there anyting on that layout that doesn't appear on other layouts? For example, portals in tabs, different colors, conditional formatting, script triggers, etc. Any information you can provide to help me replicate the issue.
Let me first say that yes, I have been known to modify a layout while users are using it.
But I am very cautious about doing so as it can adversely impact the user's experience even if there are no mistakes on my part of glitches such as this taking place. The change can "catch them between stools" and cause errors and confusion in some cases.
Having TWO different peopls changing layouts at the same time would seem to compound the risk.
By user, I mean another developer. The solution is not in production, but we are several developers working on it. TSGal, I didn't notice any impact of record modification by another user (as a matter of fact, this solution has a separate data file aka 'in separation' model)
I also don't notice an impact of which layout is modified. Even a brand new empty layout takes ages to be saved. (the layout creation time is ok, but the first modification takes a long time to save).
The only things noticeable, I told you already:
- the file is a converted solution (created using FM11)
- single user, no problem. Today I was alone working on the file. I saved layouts maybe hundreds of times. Was all perfect.
- two users : it takes a much longer time to save a layout. Several minutes.
- two users who have modified a layout (any layout) during their sessions : it becomes crazy. More than 5 (up to 20) minutes.
Now I have a question: can you explain what is the difference between a file created with FileMaker 12 and a converted solution. It seems across the forums that you (FMI staff) consider the two situations as quite different. I'd really appreciate if you could tell us more. For example, with this solution, is it worth rebuilding it from scratch? (this would take an huge amount of time, but if there is a good reason to do it, I might consider that option). Thanks, Fabrice
Thanks for the additional information.
Your initial post says, "Every time we save a layout while another user is connected, it can take up to 20 minutes!". With that knowledge, I interpreted that as one specific layout (not several layouts) while another user is connected to the same or different layout. Based on that assumption, my focus turned to that particular layout. I then asked myself, "Is the layout is damaged?" If so, create a new layout with some of the information and see if the problem exists. If the other user/developer was entering information, this could temporarily lock the layout until the user was finished editing data. That's how I came to those set of steps.
I did notice you posting it was a converted solution, and although I assumed the previous solution was from FileMaker Pro 11, I would have probably asked to confirm.
Although a converted solution should not have any effect, it is possible this is the cause. That is why I wanted you to create a new layout in the same file. If the problem persists, then create a new file in FileMaker Pro 12 , create one layout that matches the layout from the original file, and try again.
When our Technical Support department reports an issue to Testing and Development, and they are unable to replicate the issue, they ask if the file was converted from a previous version. This allows them to closely replicate your computing environment. In essence, the more information we have, the better we can focus in on a problem. It's not that we consider converted solution and new solutions differently. Every piece of information we have is considered important for analysis. If the cause is found, then it can be sent to Development for a closer look and what it would take to change it.
Thank you for your reply. I was not at all criticizing your request of more information, just in case you misunderstood my wording.
Thank you very much for the clarification about converted solutions.
Also just to be clear, I didn't take your post as criticism. I was only trying to explain how I came to the conclusions I did, and give you more of a background of what happens behind the scenes.
much appreciated :)
When i made a test for another member on this forum, i was bringed to create a brand new solution from scratch with mutliple files to more match with developer's configuration. However, i almost never work like that on the past, i mean a file for the layouts and scripts, and several related data files.
In fact, i clashed a first try that was a multiple-tables file to became a multi-file solution. All these were in Pro v12 and first, opened locally.
AND i noticed general decreased performence using the multiple file solution, even locally. I don't know if they are differences bettween 11 and 12 at this point but so... just an idea !
PS : Sorry for my bad english.
We're running into this exact same experience, but with a file that was created in FileMaker 12. Although there are multiple related files that were converted from FM11. The solution uses a separation model, so fields from the related files show frequently on the layouts of the new file.
I just wanted to see if Fabrice found a solution, or if others are experiencing similar issues. It's so prevelant (and frustrating) with us, that I'm surprised we don't see more people mentioning it.
- No active "users" - just a development environment
- One developer connected= no speed issues
- Two or more developers connected= varying speed saving any layout (cmd-s or returning to browse mode when automatically saving the layout changes) or to undo a change on a layout.
- The speed issue can be anywhere from 10 extra seconds to up 20 minutes. Haven't been able to correlate length of time with other considerations.
FMP 12.0v4 Mac (all developers)
One on the local network, two connecting in remotely.
Same here, our converted solution (multifile inhouse ERP). It behaves sometimes very badly, when FM11 is running on the same computer in the background --> dissapearing File Menu, Table names in relation dialog,.... It is not reliable for us, so we are still using good old FM11.
FMPA 12v4 (Windows XP/Windows7)
FMS 12v4 (Windows 7 64b)