davehoran

I have an old FM3 application for an agriculture program that has been migrated to FMP11 via FMP5. In the app there is a record layout in one file (Exhibitor) that includes a portal allowing modification of related child records from another table in another file (Animals). There is a button in the portal layout to take a user from the portal in the Exhibitor layout to an Animal layout in the Animals file, showing the record from the Exhibitor's portal. The script fired on the button click scrolls the records in the Animal file to the current record in the portal, then runs Select Window to switch focus to the other layout, with the fields populated with that record. This target layout also contains a portal to ANOTHER child table in another file (Classes), with related records for the Animal item in this layout. Sounds simple, and this configuration works fine in the original FM3 and converted FMP5 versions, but when it was updated to FMP11 (.fp7), when the user attempts to alter records in this Animal layout, a warning dialog pops stating "This record cannot be modified in this window because it is already being modified in a different window". It seems that the Animal record is still locked for modification from the Exhibitor portal and changes cannot be made to either the Animal record or the Classes table via the portal. The current workaround for this is to run the script on a button in the Animal layout that returns to the Exhibitor layout (the reverse of the script that got us here), which seems to unlock the record. I've looked into Commit record but that doesn't seem to work, and I tried moving the Select Window command to a script in the Animal window and calling the script from the Exhibitor file. If anyone knows how/why the record remains locked after changing layout contexts I would appreciate any insights! Dave

Update: I did find the culprit that was breaking the delete script. There is a self-join that uses a key value of the table combined with the key value of another table. I believe that when deleting this calculated field does not resolve and breaks the relationship. I removed the relationship and the process worked fine. I AM curious as to why this relationship worked in FM5: The delete process does complete with the relationship in place. What changed in how self-joins work in FM11 versus FM5?

I am working with a FileMaker application that was built and maintained in FMP4, and am trying to migrate into FMP11. The files were converted first to .fp5, then imported into FMP11 and coverted to .fp7. Overall the fields, layouts, scripts and security accounts survived the process with only some adjustments. However, there is a problem with deleting records through a portal. Our main DB layout contains a portal to another table in another .fp7 file. The Relationships chart shows the relationship, and has the "Allow creation of records in this table via this relationship" and "Delete related records in this table when a record is deleted in the other table" checkboxes set for the portal source table. New records can be added through the portal with no problem, but when trying to delete I get "This operation cannot be performed because one or more of the relationships between these tables are invalid." Some particulars: The delete button is a container field from another table/file (not the portal source file). The Relationship is keyed on an ID field, but that field is not shown in the portal; the Delete Portal Row script is preceded by a Go to Field[select/Perform] that references a name value field on the portal row. The portal source table has Relationships that also set the "Allow creation of records in this table via this relationship" and "Delete related records in this table when a record is deleted in the other table" checkboxes - so deleting the portal row should also delete rows in that relationship (cascade). Deletion doesn't even work when clicking the "Delete Record" button directly on the DB file. (I've seen on numerous occasions that this particular dialog is unhelpful and I agree - its no more helpful than the Check Engine light in your car). I will also note that this delete functionality DID work in the conversion from .fp3 to .fp5: I can open these .fp5 files in FMP5 and the app works fine. Any thoughts?