Delete Portal row - does not work

[chris7of9]

Delete Portal Row with Dialog OFF or ON, reports

[3] Command Unworkable (Wrong operating system or mode).

Any advice - as this step doe snot work, script correctly moves on to next relevant record, all the way through the DB.

I am have done a find for clients flagged as cancelled, then move to policy portal records for the client, check that policy is also flagged as cancelled and if so, wish to delete this record with the "Delete Portal Row [With dialog: OFF]", but then get the error message.

Just thought, do I have to be on the client record to delete the portal row, or in the portal.  Filemaker Help file is not much help and examples are really poor.

 

Any help appreciated.

TIS- DB Extracts 22-10-2021.pdf

[comment]

19 minutes ago, chris7of9 said:

do I have to be on the client record to delete the portal row, or in the portal.

You have to be in a portal in order to delete a portal row (which more precisely means delete the related record shown in the current portal row). Otherwise you will get error #3. 

Looking at your script, you do not go to a portal before calling the step. Instead you go to the policies layout - which means you are at a random policy record which may or may not be related to the current client record. And then you loop over a random found set in this table.

If you wanted to delete ALL policy records of the current client, you should use the Go to Related Record script step to create a found set of related policies only, then delete all records in this set. However, since you say you want to check if the policy is canceled too, the preferred strategy would be this:

Go to Layout [ policies ]
Enter Find Mode []
Set Field [ policies::status ; "Cancelled" ]
Set Field [ clients::status ; "Cancelled" ]
Perform Find []
Delete All Records

This finds and deletes all policy records whose status is cancelled and the status of their parent client is also cancelled.

 

[chris7of9]

2 hours ago, comment said:

You have to be in a portal in order to delete a portal row (which more precisely means delete the related record shown in the current portal row). Otherwise you will get error #3. 

Looking at your script, you do not go to a portal before calling the step. Instead you go to the policies layout - which means you are at a random policy record which may or may not be related to the current client record. And then you loop over a random found set in this table.

If you wanted to delete ALL policy records of the current client, you should use the Go to Related Record script step to create a found set of related policies only, then delete all records in this set. However, since you say you want to check if the policy is canceled too, the preferred strategy would be this:

Go to Layout [ policies ]
Enter Find Mode []
Set Field [ policies::status ; "Cancelled" ]
Set Field [ clients::status ; "Cancelled" ]
Perform Find []
Delete All Records

This finds and deletes all policy records whose status is cancelled and the status of their parent client is also cancelled.

 

Appreciate the feedback.  The layout I entered is the portal in question - so is my error is that I should have specified going to the portal by the portal object name and not the layout object name.  I will run your suggested code to see if it yields the required results - Thanks.

[comment]

47 minutes ago, chris7of9 said:

The layout I entered is the portal in question

No. A portal is not a layout. A portal is an object on the layout of the parent table. When you go to a portal, you are still on the parent layout and in the parent table. By contrast, when you go to a layout of the child table, you go to a different table. 

47 minutes ago, chris7of9 said:

I should have specified going to the portal by the portal object name and not the layout object name. 

A layout does not have an object name. Only layout objects - objects that are on a layout - can have object names. A layout is not an object, it is what objects are on.

Another thing: for scripts like this (scripts that manipulate data, as opposed to scripts that assist the user in data entry) you want to work as much as possible at the data layer and not rely on the presence of any layout objects on the layout. If you need to loop over the child records, it is better to do it in a layout of the child table than in a portal*.

---
(*) except for some cases where you need to maintain transactional integrity

 

Edited October 24, 2021 by comment

[chris7of9]

On 10/24/2021 at 7:38 PM, comment said:

You have to be in a portal in order to delete a portal row (which more precisely means delete the related record shown in the current portal row). Otherwise you will get error #3. 

Looking at your script, you do not go to a portal before calling the step. Instead you go to the policies layout - which means you are at a random policy record which may or may not be related to the current client record. And then you loop over a random found set in this table.

If you wanted to delete ALL policy records of the current client, you should use the Go to Related Record script step to create a found set of related policies only, then delete all records in this set. However, since you say you want to check if the policy is canceled too, the preferred strategy would be this:

Go to Layout [ policies ]
Enter Find Mode []
Set Field [ policies::status ; "Cancelled" ]
Set Field [ clients::status ; "Cancelled" ]
Perform Find []
Delete All Records

This finds and deletes all policy records whose status is cancelled and the status of their parent client is also cancelled.

 

Looking at this it simple DELETES ALL RECORDS that are flagged as Cancelled - not what is required.  It will need some kind of loop to check that the client for the policy is suitably flagged. Thanks anyway

 

[comment]

50 minutes ago, chris7of9 said:

Looking at this it simple DELETES ALL RECORDS that are flagged as Cancelled

If "this" means the script I posted then no, it does NOT do that. It deletes policies that are flagged as cancelled IF the parent client is also flagged as cancelled. I believe that is what you asked for when you said:

On 10/24/2021 at 8:52 PM, chris7of9 said:

I am have done a find for clients flagged as cancelled, then move to policy portal records for the client, check that policy is also flagged as cancelled and if so, wish to delete this record

No loop is required for this - just a simple find.

 

[chris7of9]

Maybe I have not explained it adequately, but a loop is essential, otherwise all records are being deleted.

My script needs to Find all clients flagged as Cancelled, then check if the related policies are also flagged as cancelled and if they are delete the related policies.  Then delete the client record and move to the next client and do the same - i.e. checked client is flagged as Cancelled, if it is delete all related policy records that are flagged as cancelled.

NB There will be clients that are not flagged as Cancelled that will have cancelled policies - these policies need to remain.

 

[comment]

17 minutes ago, chris7of9 said:

Maybe I have not explained it adequately,

I think your current explanation says the same thing as your original one. As I said, a loop is not necessary for this - but since you seem to know better, then obviously you do not need my advice.

 

[chris7of9]

As I said, your proposed solutions simply deletes ALL policy records.  As it does not work, it must be wrong.

[comment]

Well, you are simply wrong and I do not intend to ague about it. I am just stating this for others who might be reading this.

[chris7of9]

Likewise - i do not profess to be a guru, but the results speak for themselves and whilst a Loop is not the only solution possible, there are others.

Edited November 2, 2021 by chris7of9

[LaRetta]

Chris, I suggest you re-read what Comment said.  He is certainly correct in his appraisal of the situation.  If you get different results then you have missed something.🙂

edited:  I believe your perspective is incorrect - you must be on Policies layout and include Clients::Status in your find.  Read Comment's script again closely.

If you feel you are correct, post your script which duplicates Comment's script and let us take a look.

Edited November 2, 2021 by LaRetta