We were experiencing this issue also. Became more apparent in FileMaker Pro + Server 11 with numerous clients reporting it.
Moving to a new layout and then back (refresh) resolved the issue so our development team included a workaround to force the screen to refresh when a row was deleted. Patch up though, root of issue still unresolved.
Thank you Michael for your prompt reply.
I still have the issue on one of my machines, because it is hard to replicate. Refreshing the screen does not help, nor moving the parent record to another one and back. Even closing down the FILE of the "marketing" user interface does not help. I just found out that closing down ALL the user interfaces on the client does help. Restarting filemaker on the clients is also ok.
I have the impression that the issue occurs more on 11.0v3 than on 11.0v2. 11.0v1 was worse than 11.0v2. The same issue also occured in all versions of FM 10...
I think that Filemaker, Inc. should take this issue very seriously because I find it not professional to tell the users that they have to reboot filemaker every time this occurs...
Vincent Defrancq and Streamtime:
Thank you both for posting.
I'm having some trouble replicating this behavior. I created a new database with two tables in a one to many relationship. I then placed a portal on the layout and created a script that selects the first row of the portal and then deletes it. I uploaded the file to an install of FileMaker Server 11v2, opened it with FileMaker Pro 11v3 and repeatedly ran this script without seeing it fail to delete that first portal row.
How frequently does this occur? Should I be doing anything in addition to the above to reproduce this issue? Would either of you be willing to post a sample script that you see this issue with?
TSBear, might a copy of the problem file be helpful?
Haven't seen this issue on the windows side. My delete portal row using scripts have been rock solid so far...
i can confirm this issues - it occurs on 2 independently created solutions - one started in fm7 the other started in fm8.5. both on mac. this is a very serious issue because it entirely questions database integrity and is quite a deal breaker for a database system.
i went to devcon and demoed it at the "genius bar" / tech support desks. to toggle settings might help for a while but will not make it stable.
please fix this ..
Thanks for confirming the "delete portal row" issue. I agree with Ulrich: please fix this...
I understand that this bug is very hard to resolve since it happens sporadically. So everybody, give as much as possible input on your configuration, etc. in order to give 'hints' to filemaker Inc. to resolve this issue.
Please note that my solution is very complex, and that I think it cannot be replicated by a database with a simple one to many relationship. The issue must be caused by a combination of several elements. My marketing module (user interface) has on its own already 15 tables and 115 table occurrences... without speaking of the contacts module, and the accounting module... all related together. I have spend 3 years in order to develop these applications and this issue is driving me crazy...
I want to underline that I work exclusively on Mac machines. Also the server is a Mac mini. The data is split from the user interface. Only the data is shared through the server. Each client is running the user interface (UI) on their local machine. This is my configuration.
When I move the data on a local machine and run both the data + UI on a local machine I have NO problem, so I suppose this issue is 'server' related.
TSBear, thank you for investigating on the matter. The frequency is very hard to tell. 1 on 100 with FM 11.0v2 and 1 on 20 with FM 11.0v3 I guess. Perhaps is the frequency difference of both versions just coincidence! If you want, i am ready to post my complete solution for debugging purpose.
Thanks everybody for confirming this issue and for posting as much as possible information about this strange behavior.
A copy of your solution would be great. Please check your inbox for a message from me.
We have a large solution that has been developed over 10+ years. A large number of tables and relationships.
Since Dec 2009, we have had clients intermittently call to advise they have been unable to delete a line in a specific portal.
We have highly experienced developers who have all looked at it. In our case, a client was able to navigate to a different tab and then back which would refresh and the line would be removed.
I can count approx 10 instances of this happening across multiple configurations dating from Dec 2009 - Jan 2011.
- Macs running on standard OS/X Leopard & Snow Leopard.
- FMS 10.0v2
- FMP 10.0v3
Example of PC setup:
Windows 2008 Server
Windows 7 clients 32bit
It has also been reported by clients running FMS11 + FMP11. It is no longer an issue for us as our dev team scripted a screen refresh after every delete.
Hope that helps.
Thank you streamtime for your input.
Unfortunately refreshing the screen does not work for me. I can navigate to other parent records, even to other layouts, come back and try to delete the specific row and guess what? The row is still there... Even closing the "module" file on its own does not work. Rebooting FM or closing all the files works...
I find it basic that a database system can delete its child records with 100% accuracy...
Meanwhile I have posted a screen capture movie of the issue to TSBear. I have also posted my complete solution to him for debugging purpose. I hope they can now replicate the "delete portal row" issue and debug.
Thank you, I received your files and was able to successfully reproduce the issue. After a bit more research, it appears that our Development and Quality Assurance departments are aware of this issue. This issue comes about when a related record is cascade-created from an external file's table that's more than one away in the relationship graph.
I've attached this thread to the original report and willl post here with new information as I receive it.
TSBear, does this also happen on a Windows system? It's not something I've ever set up on windows so don't know from personal experience if this might be an issue on my side of the fence, but the Known Bug List would like to know...
This issue is completely OS independent so Windows would be affected as well.
The issue I run into, and it may be related, seems to be connected to filtered portals.
Let's say that I have a portal with the following record types.
If I filter the portal to only show "B", and then I delete the portal row, it doesn't delete "B", it deletes the first "A". If I continue to hit the delete portal row out of frustration, eventually the first "B" will be deleted, but only after all the previous As were.
Best way to see this in action is to have two windows looking at the same portal, with a different filter on them. Try to delete the first record in the B filter, and watch what happens in A.
THIS IS A SERIOUS PROBLEM!!!
Thousands of clients are probably deleting tons of records, and are not even aware that they are doing it.
I don't know why it took this long to catch it.
Nuts. Now I can't replicate it. What in the world is going on?