I have had this happen before as well and there has also been no explanation that I could discover. It is not consistent for sure, but the Delete Portal Row wouldn't work, but deleting that same record from a primary layout of the those portal records does work.
For those portals where the issue occurred I scripted deletion in other ways and did not use the Delete Portal Row script step.
I had a similiar problem in the past. The problem revolved around three tables connected by the Parents PrimeKey.
As far as I remember it was setup something like this and I may not have this correct.
P = Parent, PID = PrimeKey
C = Child , PID = ForeignKey
X = Other, PID = ForeignKey
P to C by PID allow create & delete
P to X by PID allow create & delete
C to X by PID no create or delete
This may or may not be the answer, but it may be something to check for.
One tiny question: Had the newly created record been committed when you pressed the portal's delete buton?
Can happen even if you move off the record, jump to another table, and return to the record with the portal. Will allow you to delete the related record if you allowed the user to view the portal records in their table and bot through a portal, but this defeats the purpose of deleteing a portal row.
Other users may be able to delete the record. Eventually the creator can delete the row.
A bug, and reproducible in even the most simple example. Generally happens as a guest and not in single-user.
Might also try adding a Go To Field script step at the end of your script. This has resolved many a portal problem for me.
Carsten: Yes, the record is committed at the time I try to delete the portal row.
Thanks for the suggestion, Jon. I tried this, but with no improved result.
Scott: I didn't happen to find any discussion that sounded like this exact scenario. Where did you find this bug mentioned?
I was able to reproduce the problem again today, and again not consistently. I created a related record in the portal of a parent, comitted, and could not delete the row. Did the same in another record, same layout, but was able to delete it. Came back to the original record and could still not delete the row. Quit and re-opened and could delete again.
I see this in our system from time to time when any one of the following happens:
- User's permissions in either table, parent or child, does not allow deletion of records. If the tables are in separate files, this is even harder to resolve.
- Either the parent or child record has not been fully committed to the server (this can take several seconds even on a LAN, much longer over WAN) before the Delete command is processed. Entering data to create a record via a portal leaves both parent and child uncommitted, and clicking a button IN the portal row can leave them both uncommitted.
- Child record to be deleted has a validation issue (mnissing required field value) which is not resolved prior to the Delete command being triggered. Reuired values have to supplied to allow the commit to execute.
These are not obvious problems to the users, but the examples you've described of viewing records from another layout and then going back are scenarios where network latency and commit issues may have resolved in the meantime. In other words, just messing about elsewhere might appear to solve the problem because time has passed or layout changes allowed the commit to complete.
Buttons in the portal row which simply execute the delete portal row step without a script to commit the records and then return to the correct row for deletion can fail to commit the record and may fail to execute on uncommitted rows.
Good luck. It can be a trial to troubleshoot exactly what's going on with portal row deletions. Users are often unable to reproduce the problem if the problem is any form record commit issue. The button fails, then later it works on the committed record, and the user thinks nothing changed escept that the problem went away.