Losing communication with the server even for a moment will cause all uncommitted changes to be lost. I've had this happen. Best to go to browse mode after a small amount of work if you're modifying a hosted file.
Rick, this is not the case. We are talking about changes that have been committed to the layout over a period of an hour of work or better. Saving the layout going back into layout mode back and forth for an hour and then all of a sudden the layout is gone like it was never saved to the server any of the times that it said it was saved previously. I am a senior FileMaker engineer for Richard Carlton Consulting and this is not standard behavior.
Thank you for your posts.
Is this occurring with all files or just a specific file? I'm trying to determine if this is a damaged file or FileMaker/OS issue.
If just a specific file, is the issue occurring for one layout or all layouts? If just one layout, try creating a new layout (do not duplicate the bad layout) and move the desired fields and objects onto the layout.
If you were performing these steps on a hosted file, does the issue occur when making the changes locally and then uploading the file to the server?
Any other information you can provide may be helpful.
Although I don't have a solution to your issue, I've never had FileMaker tell me a layout, or changes to a layout, was saved. I do have it set to save layout changes automatically though. Do you? And you're working on a live hosted file, yes? If you're not automatically saving layout changes this still seems to me to be a network problem. Even if save layout changes is set to automatic, the changes don't seem to "commit", in my experience, until exiting layout mode. I've lost hours of work when working on a layout when a communication problem occurs and I've neglected to exit layout mode from time to time. My two cents. The alternative is to download the file and work on it locally.
Rick, yes it is hosted. Yes I am saving changes automatically and did so multiple times during the time I was working.
TSGal, this has happend on more than one file and more than one layout but it only happens intermittently. (A total of 4 very obvious instances now within the last month) I have not tried to make the changes locally (as I generally work on live files) but I doubt that it would have the same problem. What it feels like is that FileMaker client thinks that the save was successful but FileMaker server or its cache or something is not retaining the save. I recently uninstalled 13 and another possibly conflicting version of FileMaker and re-installed only 13 and I will see if it happens again.
This is the second such report of this issue. Other users and FileMaker Inc. have been unable to replicate this behavior, but it has happened to at least one other person (Howard?) from what I can recall...
I have also experienced this issue. It is on a hosted file, and has happened on many different layouts (of one file), randomly over the span of several months. I was able to catch it in the "unsaved state" where my client shows the new layout changes, but when anyone else logs in, they see the unedited version of the layout. I can navigate through the database using scripts, editing other layouts, and come back to the layout in question and it still shows the changed version of the layout. In the unsaved state, I can:
- change and save multiple layouts, none of which anyone but the editor can see.
- create a new layout, which no one else can see
- create a script, which everyone else CAN see
- create a table, which everyone else CAN see
- create a new style, which everyone else CAN see
- the layout automatically created by the creation of the new table can be seen by me, but no one else
- when I create a go to layout script step, I can select the layout I created, but then it shows as Go to Layout [<unknown>] in the script
- I can see my new layout in security, but no one else sees it in security
- If anyone else edits any layout and tries to save it, their filemaker client locks up
This behavior can persist indefinitely (at least several hours), until the "editor" closes the database, at which point everyone can save layout changes again. When the editor logs back in they can also make changes again.
Much of what you report sounds like a caching issue. Although generally not necessary, have you tried executing the script step "Flush Cache to Disk" on your machine and the other user's machines?
It's also not clear in your post if all users have [Full Access] privileges. If the other users have custom privileges for specific layouts, I could understand why the other users would be unable to see a new layout.
Any other information you can provide may be helpful in replicating this issue.
I have not tried flushing the cache, I will try it if I can catch it in that state again.
- All users testing had [Full Access]. And by users, I mean me connecting from several different computers.
- The file is connected to a MySQL database via ODBC, and has many ESS tables.
- There is high latency between the server and the developer.
- There are multiple developers working on this file simultaneously.
Let me know if there's any other information I can provide
I found myself in that state with the inability to save layouts again.
I tried "Flush Cache to Disk" on both machines. It had no effect.
This doesn't have anything to do with custom privileges as it affects layout changes as well. They can see the layout but not the new changes.
In this case I had added a new object to a layout. The user could not see it, even though I added it an hour ago and had navigated to several different layouts in the meantime. When they reported they couldn't see it, I went to that layout, went into layout mode and copied the object. Then I proceeded to restart my FileMaker, paste the object on the layout, save the layout, and they could now see it.
Sorry, I don't have a solution, but I can confirm the behavior you described.
I have a client with the same problem - she is using FileMaker Pro Advanced 13.0v9 on Windows accessing a remotely-hosted database (at FMPHost/FileMaker Hosting Pros) running FMS 13.0v9.
We regularly conduct training over the phone while both accessing the database at the same time from separate locations. I am on a Mac running OS X 10.10.5 and FMPA 13.0v9, and we are careful not to both edit the same layout at the same time, or not to both go into Manage Database at the same time.
We have had several occasions where she makes a change to a layout, goes to Browse mode and can see the changes and enter data, but I do not see her changes. We have taken screen shots of the that layout at the same time, and hers shows the changes while mine do not. We both log out and back in, even quitting the app, and sometimes her changes disappear and sometimes they do not.
Up until yesterday, my theory was that the remote server was not writing cached changes to disk.
Here's where it gets more bizarre -
A few days ago, she made some changes that she could see, but her colleagues at her office could not. A day later, the problem persisted. Two days later, her changes were gone from her computer, too.
Same problem here. I'm running older versions of Filemaker, though (if it ain't broke...), so I thought it would be helpful for everyone to know the problem isn't limited to the versions listed above.
We have server version 9
Users are using FMP version 9
I use FMP Advanced version 11
Everything has worked flawlessly with this combination of apps for several years, now. However, the problem described above popped up with one particular layout. I made a change to a text on a layout, and have been using the changed version for weeks, but users only see the previous (unchanged) version.
This is what solved it for me:
- Created new layout (did NOT use the duplicate feature)
- Deleted header and footer (old layout just had one part: body)
- Used Select All to copy all objects from original layout
- Pasted all objects into new layout
- Changed scripts so they point to new layout
Ok, this is embarrassing... I should get a DORK award!
The whole problem we were having boiled down to me having two layouts in the system, and only making changes to one of them. I was also using button A to reach layout A, whether I was on my machine or one of theirs, while some users were using button B and reaching layout B.
I would make a change to layout A, test it on mine and theirs using button A, declare it updated, then get confused when they couldn't produce the same results (because some of them were clicking button B).
Why two layouts? I did it in a rush one day as a quick solution in two different files, so they could each print a certain form we needed. I should have taken the time to do it right, using only one instance of that form (layout), because I sure paid the price in time and frustration while tracking this down.