I am using a script to delete all related records in a portal called 'general'...
It only deletes the first row ... I think there is something wrong in the loop ....
Debugger shows the following .... cant make sense of it ...
Fixed it ... This is working perfectly !
If you're on the first portal row record, and you delete it, you're now on the next portal row, because that's now the first. Don't need to go to next portal row.
Actually, you're going to next record, not next portal row, so that would be an even bigger problem.
Go to Portal Row [ next ; exit after last ]
I am getttng a spining beach ball and the mac-command icon ... I think its in an endless loop
Since you are obviously trying to delete all child records related to the parent, why don't you just use GoToRelatedRecord > Result Options > Show Only Related Records > Match Current Record Only and then Delete All of the related records.
Go to Object [Object Name: "gerneral"]
Go to Portal Row [First[
Delete Portal Row (no dialog)
Go to Portal Row [next;exit after last]
erolstOct 12, 2015 6:56 AM
Just keep in mind that you will get into an endless loop with this UNLESS your "allow creation of records" is disabled in the relation on the relationship graph.
Go To Related Records can do this without the loop, but be careful. If the portal is empty and you don’t either check for no related records before the GTRR step or an error code immediately after the GTRR step, Delete All Records could delete all records from the wrong table.
The recommendations to Go to Portal Row[next] are misguided.
If using Go to Portal Row, then [first] is the correct choice, though I suspect you don't need any Go to Portal Row (as Extensitech indicates).
I think you could make that more efficient (and correct):
Go to Object [ Object Name: "general" ]
Go To Portal Row [ Select ; First ]
Exit Loop If [ IsEmpty ( GeneralReport_Village_Colony::ReportID ) ]
Delete Portal Row [ No Dialog ]
No, that one is not working
but it if you read back thru this thread, several of us have pointed out that you don’t need any loop at all.
true, but there might be situations where you do not want to leave the layout or open a new window.
Seriously, I'm not trying to ignite an argument, just having trouble seeing why you couldn't open a hidden window with a found set of records to delete and deleting them. The result for the user is identical and has many advantages. For one thing, layout focus and object status will be (nearly always) unchanged by such an approach. This can avoid tripping script triggers for one thing.
Transactional model? Deleting records and changing other data. And if anything goes wrong then reverting back?
But delete found records would be a single transaction no? You would have to modify some and delete others in your looping script—not what happens in this example script.
If you - say - want to set a statusflag in the master record that the related records have been cleared and want to delete the portal row records and have that all in one transaction going to another layout would not work. Because using your method that would be two transactions (or actually as many transactions as there are records - if you hit cancel while deleting 50000 records you won't get the ones already deleted back or do you?) .
All good points. Just seems unlikely to be an issue IF you are simply deleting all the records or a block of them. Only when you also want to modify data, such as setting your flag in the parent record does there seem much of a need to make it transactional. (and some of my tests suggest that you can do this without the portal though the approach is slightly different.)
Admittedly, I'm not a big fan of using a script to loop through a portal. I've seen a lot of issues and potential issues brought about by such a layout design reliant approach. Future layout changes, for example, can easily screw up such a script in a number of ways.
Yes, layout changes are a problem. Thats why one should always use a layout designed for that purpose. Or at least create a portal for that very purpose, put it in the cut off part of the layout and lock it (with a warning text above it or so)
Retrieving data ...