Thank you for your post.
In Layout Setup, is the table area blank? Or, is an unrelated table displayed?
Does the client have a limited user account? If so, what are the privileges for Records, Layouts, Value Lists, Scripts, and Available Menu Commands?
Did the user go into Layout Setup and make any changes?
Any other information you can provide may be helpful in narrowing down the possible causes.
In edit mode the table is blank, if your in layout setup is shows the unknown table text <>, It doesn't show a table it's not supposed to it just loses the table it was associated with.
The users reporting it have had full access level to the database. When it happened the user reporting it is not editing the db. It is possible that the layout in question was edited within a few minutes of the issue.
It's happened to me once and I'm on the local network with the server, and I believe it's happened 3 times to the other admin and she is remote.
Our server is running version of Filemaker server 220.127.116.115, I am on FMPA 13 on win8.1 and the other admin is on FMPA 12 win7 sp1.
The first time it I downloaded, verified, compressed and reuploaded the database but that hasn't seemed to help.
Thank you for the additional information.
How many users have full access privileges to the database? How many would want to make changes to the layout on a live system? Are other users logged in when changes are being made to the layout? These questions are more rhetorical. That is, you should limit the number of people making changes to a layout, and when making changes, you should make sure others are not accessing the file.
Back to your original information, after the person exits Layout Setup without making any changes, can the user quit and relaunch FileMaker Pro, access the file and then see the table listed? If not, can the user select the desired table for that layout? Is it possible that the table was previously deleted?
The next time this occurs, try and find all possible parties that are making changes and find out what they have done. This may help know where to look next.
To answer how many have full access 2, I would prefer and usually do make edits in an offline copy and then add them to the live db. Our db is live 24/7 so users are in there all the time. unless we are down for server upgrades.
Back to your original information, after the person exits Layout Setup without making any changes, can the user quit and relaunch FileMaker Pro, access the file and then see the table listed? It is a random issue I can't recreate it to test that. If not, can the user select the desired table for that layout? Yes, it can be put back after it drops off the layout Is it possible that the table was previously deleted? No, the table is there but no longer associated to the layout.
The next time this occurs, try and find all possible parties that are making changes and find out what they have done. This may help know where to look next. The only reports I have of it happening is from myself and the other admin who would be the only ones editing the db normally.
Between the layout and a table lies a table occurrence--a box in manage | Database | Relationships. When you "select a table" in the Show Records From drop down for a given layout, you are actually selecting the name of a table occurrence. Could it be that a table occurrence was removed?
If a table occurrence is removed, you'd get the results reported, but you could still "put back" the table by selecting a different table occurrence that was not deleted and repointing the fields etc to refer to this other table occurrence.
That sounds like a long shot here, but since it fits your description, it would help to be able to fully rule out that possible out come.
I'd also recommend taking a very recent back up copy of the file and running a recover on it to check for any possible damage to your file to in order to rule out file corruption as a factor.
Thanks again for the information.
At this point, this type of error has not been previously reported, so I still need your help in trying to narrow this down. Keep track of the times when this is working correctly, and either you or the other full access user encounters this issue, contact each other immediately to find out exactly what has been done. This may help provide a clue. Since you and the other user are using different versions of FileMaker Pro (12 vs 13), this may be a contributing factor. I really don't know.
I have exactly the same problem.
I already tried to post an answer 2 times but I don't know if you received them...
Thank you for telling me if it works
No I don't see any other comments from you. I was able to restart the server fms12 and most client use fmp13 to access which seems to fix the issue. Which i am guessing is cause by trying to edit the database with version 12 after editing it with fmp13 or fmpa13. Again this is pretty much a guess but it might help you.
I already tried to post an answer 2 times
Due to a noxious forum bug, please protect yourself with a "Select-All, copy to your clipboard" action just before submitting a private message or comment to this forum. The bug can lose your comment and log you out of the forum--forcing you to sign back in and re-enter the comment or message. By copying to the clipboard before posting, you can re-enter your message by pasting from the clipboard instead of having to retype it all over again.
Pierre, did you check any of the things TSGal and I suggested that Denham Morgan check?
In particular did you check to see if your file might be corrupted.
Simply running a script should not in any way modify the design of a layout--which is what has made this issue very strange...
Thanks Phil, it experimented it 3 times…I thought it was my mistake ;-( …Now I am going to type it in TextEdit before I post it...
Well, I have exactly the same bug than Morgan...
FileMaker Server 18.104.22.1685 on a Mac Mini running Mac OS X 10.8.5
8 clients on imacs running
- Mac OS X 10.9.2 with FileMaker 12.0v3 (5)
- Mac OS X 10.9.2 with Filemaker 13.0v3 (2)
- Mac OS X 10.9.2 with FileMaker Advanced 12.0v5 and 13.0v3 (1, mine)
After working with FileMaker for some time, I go to modify a layout and when I try to save and exit, I get the spin/beach ball for 45 to 60 seconds, I lose the link from that layout to the TO and the right limit of the layout shrink to the left in the middle of the layout. I think it happen for complex layouts, but I try not to reproduce the bug because I fear one day I cannot put back the link for good and it would be a catastrophe!
If I try to put back the link or set the right limit to where it belongs, it doesn’t work and go back to the previous state.
I duplicate the layout, I open the Manage Layout list, I put back the TO on the original layout from that list, I open the initial layout from that list and set the limit where it belongs and then I can save normally. After that I open the duplicate layout from the list and delete it.
Problem 2 (Possibly related):
Users complain that they see more and more the spin/beach ball and have to wait before they can interact with the database, even to just enter a value in a field.
They also complain that FileMaker crashes 4 to 5 time in a working day. It also happen to me 2 or 3 times a day. FileMaker should have received all these crash reports.
Bug 1 and Problem 2 begun at the same time so I think they are possibly related.
I hope FileMaker can help me on that one because without any solution it would mean I cannot modify the database anymore and the users could decide they don’t want to use it anymore.
Thank you for your help,
Have you tried running a Recover on the file? If so, were any errors reported.
After making changes to the layout and uploading the file back onto the server, is this when the users complained about the file crashing "4 to 5 times in a working day"? Your time line isn't clear.
I did not try to recover the file, I will do it and keep you informed.
I change the layout with FileMaker Advanced directly on the live database, I do not download and upload it.
The users complain independently of what I am doing. The FileMaker client crashes anytime even if they are doing something else on their machine...
Thank you for your help,
When the clients crash, do yo notice anything common? That is, are the clients all crashing when they access a specific Layout? A specific table? A specific record? Are there any script triggers active that access similar tables? Fields?
Updating a layout on a live database could have serious consequences if others are also accessing the file. For example, removing fields from a layout when a field is being updated by the client. Therefore, it is recommended schema and layout changes be made when clients are not accessing the file simultaneously.
As I told you the client crash happens even when they are doing something else on the computer (Working on a XL sheet, Entering a Word document, answering an Email,...)
I am the only one modifying the database. I do not do anything "Dangerous" on the database when everybody is using it.
I'll come back to you as soon as I will have recovered the database.
Thank you for your help,