Have you selected the "save layout changes automatically (do not ask)" preference?
No, you are *not* crazy. I had it happen yesterday — lost some layout changes while working in 13.
I was working on my office LAN, hosting by FMS 12, clients FMPA 13 and FM Go 12. I created a quick-and-dirty table in a child file to do some data hygiene, since dirty data happens, esp. in a client-developed database that's been in use since 1996. I built the table, amused to discover that the FMPA 13 layout wizard puts you in Modify Table View to create the table. Cleaned up some data, went on to something else. Later returned to the table - what the heck, it has no fields! Where did they go?! Hurried on, rebuilt it, scratching my head, but marching with the To Do list.
Barbara Levine | MicroServ LLC | microservllc.com | 203/776-6800 | FileMaker 12 Certified Developer | FileMaker Business Alliance Platinum Member
Marking "save layout changes automatically (do not ask)" is usually the very first thing I do after installing a new version of FileMaker. Yes, that was marked AND I'd entered/exited layout/browse modes multiple times with all my changes (theoretically) getting saved each time. They were at least cached on my local machine, but it seems those changes never got saved to Server.
And -- I have the opposite setting selected, but worked with the data in the table in browse mode, so obviously the fields got added to the layout. So that's not the determining factor.
Good to know. I asked the question just in the off chance that it makes a difference when the TS personnel try to replicate this issue. Of course, given the fact that this may well be an issue that only occurs at apparently random intervals will greatly complicate efforts to reproduce the issue.
Thank you for your posts.
How many times have you made layout changes successfully, and how many times has this issue occurred? Assuming the issue has occurred a minority of the time, what can you tell me about the server? Is it possible that the server was updated, or the server was moved with a backed up file? The latter wouldn't make sense as the updated scripts and fields are present.
Is this possibly a RAID System?
Is there anything in the Event Log? Any large gaps in times?
Anything else you can provide about the computing environment may be helpful.
I make frequent layout changes, all day, every day, and most of my work lately has been in 13. Even with the two particular solutions in question, I was or am making frequent layout changes, and this loss of changes is a very infrequent occurrence. There have over time, of course, been small changes I thought I made that aren't there, and those are easy to chock up to bad memory (mine, not the machines or software). But these two instances I've noted are situations where I am absolutely positive of the changes that were made.
In neither of these two instances has the server been updated or files moved/replaced. In both cases, nightly backups are done and in neither case do the those nights' backups contain any of the layout changes. I also tried in the second case to perform a recovery of the file, to see if the changes returned or any errors were noted; there were no issues found there.
Barbara noted that her files were old, which I considered as a potential factor. The database in my first instance was created around FM8, but the one in the second instance was created from scratch in 13.
In case one: Windows Server 2008 R2 Enterprise (SP1) with 12 GB of RAM and a ton of free space on all drives. The OS is RAID, but the location of the DB files is not; DB reside on an SSD. There were no other users in the database at the time of my changes, and overall server usage at the time would have been extremely low to nothing. I'm not able to check the logs, as "only entries in the last 15 days can be viewed". (Really?!?). But checking the Windows application log, I see there is no unusual activity that day and no noticeable gaps (there was a server-side script schedule that ran every 15 minutes).
In case two: Windows Server 2008 R2 Standard (SP1) with 15 GB of RAM and a ton of free space on both drives. I'm awaiting word from IT as to whether it is set up as a RAID and will let you know if it turns out to be RAID. Server has light use -- maybe up to 5-8 people scattered throughout the day, with no other users in the particular database I was making changes to. There were no notable log entries or noticeable gaps.
Hope that helps...
Thank you for the information.
Nothing looks out of the ordinary in the computing environment, but I still don't have an idea why this is occurring. With two people reporting this issue (yourself and BarbaraLevine), and since this issue has not been reported previously with any version, I am definitely interested into the cause.
In your first case, you were using FileMaker Pro 13 with FileMaker Server 13. In the second instance, and with BarbaraLevine, there was a mix of FileMaker Pro 13 with FileMaker Server 12. Not taking anything for granted, I just want to verify the first time this occurred was with FileMaker Pro 13 and FileMaker Server 13.
What kind of changes were being made to the layout? Assuming the changes were general, were you using the Inspector to move objects? Manual dragging of fields? Adding fields?
And when you saved the changes and viewed them, everything looked fine?
In case of a cache issue, was the server ever stopped/halted?
Obviously, I'm on a fishing expedition, and I need as much information as possible, or some possible scenarios to try out. Until a cause is found, I would duplicate a layout after I finished my edits. If the layout reverts, then you'll have the duplicate layout to use.
Please continue to keep me updated.
I am reluctant to say the FMP 13 on FMS 13 was "the first time this occurred", but it was the first time I really took note and was absolutely positive I had done what I thought I had done. In both of my cases, we were doing major changes and I have/had a record of each individual item on my list checked off as done.
In my case one: layout theme of both copy and paste layouts is "classic". I'd copied ALL layout objects from layout #1, went to layout #2, deleted all objects, and pasted what I'd copied from layout #1. Objects included fields, graphics, text, portal, buttons, popovers, objects formatted with conditional formatting or invisibility -- really just your standard data entry form layout. After pasting, my task was to set all fields as inaccessible while in browse mode, most buttons inactive -- it is supposed to be a view-only version of the editable layout I'd copied from. I doubt I would have used Inspector to move objects; I definitely used the keyboard arrows to move things. I probably used CTRL-Z and/or CTRL-Y to undo/redo at least once or twice. Unlocked and locked objects, grouped and ungrouped objects, ungrouped and had to reassign invisibility, etc. Likely no manual dragging of fields and definitely no new fields added to the layout. Switched to browse mode a few times (auto-save of layouts) to check for any fields or buttons I missed, etc, and all looked good in browse mode when I was done. But NONE of the changes were saved. FWIW, I just tried the same thing again using a copy of the original first layout and copying again from the second layout. No problems this time.
In case two: layout theme is Onyx Touch on two form layouts with a sliding panel covering much of the layout. Changes included moving fields (by mouse or keyboard), adding additional fields to the layout (definitely NOT with field picker; possibly via dragging of new fields onto layout; most likely, however, by duplicating existing fields and text into new objects with CTRL-drag), adding buttons and deleting popovers, resizing multiple objects manually with mouse and then using Inspector to manually fix each of those objects' sizes and positions to the nearest whole number (don't get me started on this huge time-wasting FM 12+ frustration), setting object tab order, switching slide panels to effect similar changes on different panels, and then on a second layout, etc. Switched to browse mode a few times (auto-save of layouts) to see how things looked and back to layout for more changes, and all looked good in browse mode when I was done. But NONE of the layout changes were saved (only the field and script changes). ESS tables involved here, so saved changes included resyncing a table or two with MySQL, as well as changes to a FM-based table.
Hope this info is helpful...
Thank you for the extensive notes and recollections. Although it still doesn't help me locate a possible cause, the issue is now public and I'm hoping others who encounter this issue will chime in.
We have talked privately, and I'll continue to monitor this issue internally.
I had a very strange thing happening to me today.
I had been working on a layout in one window. Then returned to Browse mode by simply hitting cmd-B. Clicked Save when the question came up.
Then I needed to do some stuff so that this one window was visible in Browse mode while I opened a new window (with the same layout).
Went into Layout mode to do some stuff there. And I got this locking message ("This layout cannot be modified in this window because it is already being modified in a different window.").
What?? The other layout was in Browse mode. I made triple sure that I did not have any other window open with that layout.
Remembering the discussions about the issue of disappearing layout changes I went back to the original window. Went into layout mode, selected an object (no complaints, the other window still on layout mode on the same layout).
Moved the object a point or 2 , then undid the move. Now I explicitly saved the changes before going back to Browse mode.
Moved to the other window, and now, sure enough, I had no problem working on the layout in this window.
The original window was open all the time.
It seems, that the ability to undo layout changes somehow have messed up the save command when going directly from Layout mode to Browse mode.
The "workaround" is to always first hit cmd-S before hitting cmd-B.
Hope this helps in catching the insect.
Thank you for your post.
This issue has been reported to Development and Testing under "howards", and I have attached your comments to that report. If any other information becomes available, I will let you know.
We have seen this occasionally while running FileMaker Pro Advanced 12.0v4 on OS X 10.6.8 working on files hosted on FileMaker Server 184.108.40.2065 running on 10.8.5 on this Mac mini...
...2 hard drives RAID 1 using Apple RAID built in software (Disk Utility).
Hope that helps track down the issue.