I'm sure there is no documentation on this problem yet, but it has been reported by a number of people in other forums. Some people at FMI may be aware of the issue, but I'm sure it would be helpful for TSGal to follow up on it.
SWS and howards:
I am not aware of this issue.
howards - If you have links to other forums, please let me know. I'll be happy to follow up on it.
I am unable to replicate the issue, but then again, the most complex file I have here contains 50+ tables and 100+ scripts.
SWS - Do you have a clone of a file before the structure was changed? I know your solutions are more complex than the average user, so I'd like to be able to have a live case to show than have others here (especially Testing) trying to replicate the problem. If the file is confidential and you cannot send it in, I'll respect that decision.
If anybody else reading this thread has encountered this issue, please let me know either publicly here or via a private message.
I have not encountered this. Perhaps this is related to specific OS? I am on XP.
This is most definitely a bug, and I have experienced at great length and frustration within the last couple of days. I am able to reproduce it every time when I rename a field on my table, and commit the change. Prior in 10, you may have seen this "applying changes to layout' dialog if making a change over wide area network, or VERY briefly if local, but in 11 you literally see it take 3 seconds per layout in your file. My file has over 250 layouts so this dialog actually stays open for a heck of a long time unless I skip it.
The crazy thing is, I don't know what it is actually doing to the layouts, many of the layouts it "applies" the change to, aren't based on the table where I have made the field rename. The only thing I can possibly think it is doing is going thru and seeing if the field exists on those layouts with a default label, and renaming that label... but other than that I'm stumped.
My OS is 10.5.8 mac os x, running FMP 11 Advanced, database in question is 2 file Interface/Data separation solution, problem happens when making change to Interface file table - though I'm sure the multi-file structure of the database is not the reason here...
I hope this can be resolved with the next update because it really is super annoying.
This is happening for me on Vista, Win7 and Mac OSX (not tested XP)
Adding a field is ok, but renaming or deleting a field and your in for a long wait on a reasonable sized solution.
Just to add, in case it is of importance, my windows machine is a 3.2ghz Quad core, with 8gb ram (i know FM only uses 1/2 that)
but the machine is more than capable. I dual boot into Vista / Win 7
The Mac is a 3.06ghz Core 2 Duo with 4gb ram (OSX 10.6.2)
My solution has around 65 tables, 300 TO's 2000 fields, 1500 scripts and 550 layouts give or take a few...
I wouldn't describe the layouts as being over complicated, but they are also not 'basic' (well some of them)
For instance I can go in now (on any machine) and add a new global field to my globals table.
Click ok to exit... fine done immediatly.
Go back in and delete that field... 1 hour wait
There are posts on tech talk regarding this too, but I though it beneficial to be on this forum due to the known bugs list.
It would certainly be nice to get some official clarification on the behaviour of the skip button, if its safe to use then its not going to concern me much. On a side note to that, I do not use any field labels based off the original field name (when created)
Thank you for your input.
Do you have a clone of both files I could use for testing purposes? I will try it with both Mac and Windows and report back. This will also give a real-life example to our Development department so they can trace what may be causing the issue.
Let me know, and I'll make arrangements to obtain your files.
This is not a bug, this is an amazingly stupid "feature", because FM Inc actually bothered to draw dialog box with progress bar detailling whih layout is processed (so that's new code)
see the picture (oops we can't attach picture, only link to them)
one other mindless design choice !
FMPA 11 pre-realease
The dialog has always existed, if the connection is slow (i.e WAN) or there is a lot of work to do, the dialog will show.
However, just for comparison I did a little test.
I created a new blank file in filemaker 11, created 18 fields, 1 layout with some fields on, then 603 blank layouts.
I split these up into two folders..
I made 2 copies of the file at this point, just to be consistent.
I opened copy 1 under Windows & Filemaker 11 and deleted one field - it took around 18 seconds to complete, meanwhile showing me the dialog for updating layouts, I could clearly see EVERY single layout number being show in sequence (although pretty quick).
I then opened copy 2 of the IDENTICAL file under Filemaker 10 (on the same system) and deleted the same field.
It was instant. So I went back in and deleted ALL the fields in one go... again it was instant !
I can also repeat this on Mac OSX 10.6.2 with almost identical results between 11 and 10.
Now bear in mind this is basically a skeleton file, no data... no layout elements.. 1 TO, nothing but text fields defined
TSGal, to save you asking for it (in case you was going to), I have send you the file as per previous instructions, I hope this helps somewhat... :-)
Edit : Ok... I missed the part of your first post where you did ask... :-)
In the meantime, if you could clarify exactly what skip does and if it will have any future implications, that would be a great help.
Also it has come to my attention (which I confirmed with testing) that if you for instance delete a field from two or more tables, the 'applying changes to layouts' repeats itself for each table in question.
If you delete 1 field from 2 tables, it will apply layout changes twice.
If you delete 1 field from 5 tables, it will apply layout changes 5 times, therefore increasing the time dramatically
For more reference here is a post on the non-public techtalk : FM11 - Applying Changes to Layout "xxxx"
Sorry TSgal I can't really give an example of the solution in question as it is a client solution. However judging by other responses I doubt you'll have any trouble recreating this issue.
Thank you to "SWS" for supplying a test file. The file had approximately 600 layouts (two folders of 300 layouts each), where most of the layouts were blank. Changing the name of one field (of 20 fields), takes several seconds to update in FileMaker Pro 11, where it is instantaneous in FileMaker Pro 10. To make matters worse, if I go back and change the field name back to the original name, the time to update has increased.
I have forwarded this example file to our Development and Software Quality Assurance (Testing) departments for review and confirmation. I will keep everyone updated when I receive any kind of explanation.