Having trouble with a deletion formula

HCL Domino Domino Forum
1

Well, sort of…

I’m trying to rewrite a little formula that will roll through all of the documents in a database searching for rep/save conflicts. When it finds a rep/save conflict, I want it to set a field named “Deleted” to “Y”. Doing this will remove it from all of the views that the users see - basically, soft deleting it. Because of business needs, I do not have the option of hard deleting the document.

I currently have it set to run from the Action menu and it is set to act on all documents in the database. When I run the agent with this formula, it kicks off and seems to run, but doesn’t delete any of the replication/save documents that are in the database.

If someone could take a look at what I have below and point out any errors, I would really appreciate it.

@If(Form!= “FormA” | Form=“FormB”;@Return(“”);@Success);

@If(!@IsAvailable($Conflict);@Return(“”);@Success);

FIELD Deleted:=“Y”;

SELECT @All

From what I can tell, this formula should do the following…

  1. If form doesn’t = “FormA” or if Form = “FormB”, then it stops running. If finds the opposite to be true, then it moves down to the next line.

  2. If it doesn’t find any conflicts, it stops running. If it finds a conflict, then it moves down to the next line.

  3. On the documents found that match the above criteria, the formula will set the field “Deleted” to “Y”

  4. I know that the “Select @All” statement is thrown in there to tell the formula what docs to run on, but I still haven’t figured out why it has to be at the end of the formula.

Seems to me like this should be working, but I’m just a dumb admin getting aquainted with the wonderful world of formula language. Whee!

2

Subject: Having trouble with a deletion formula

@success and @failure should be used in input validation formulas, try this:

SELECT Form = “FormA” : “FormB” & @IsAvailable($Conflict);

FIELD Deleted:=“Y”

By changing the select to only run on rep conflicts for forma and b, it will also speed up your agent.

(not tested)

As Paul suggets, you could also change all your views but this might not be feasible if you are an admin and don’t feel comfortable.

3

Subject: Having trouble with a deletion formula

you don’t need to add a filed to your rep/save conflict docs as there is already a field that determines whether it is a conflict. Just add code to your views to exlude any docs with the field $Conflict (SELECT !@IsAvailable($Conflict)). The create another view with the selection formula SELECT @IsAvailable($Conflict) and this will hold all of the conflict docs (make sure show response docs in hierarchy is deselected in the view properties). Now you can just run a simple agent against this view to delete any docs in it.

4

Subject: Having trouble with a deletion formula

On second thought… maybe it wasn’t the formula that was the problem after all. I just created an agent to run the Simple Action of changing the ‘‘Deleted’’ field value from “N” to “Y” only on selected documents and even that failed change the value of the field.

It’s a Computed when composed field, but that shouldn’t be a problem, should it?

5

Subject: RE: Having trouble with a deletion formula

You state “I just created an agent to run the Simple Action of changing the ‘‘Deleted’’ field value from “N” to “Y” only on selected documents and even that failed change the value of the field.”

Are you looking at the value of the DELETED field through document properties after you run your agent?

6

Subject: RE: Having trouble with a deletion formula

no, it should not matter that it’s a computedwhencomposed field; the agent should still be able to change it

7

Subject: RE: Having trouble with a deletion formula

I too am having trouble creating and setting field values on a rep/sav conflict document.

I have a formula agent that sets a hand full of fields with deletion values that causes the document to appear in a different view to be hard deleted later, but nothing happens when the document is a rep/sav conflict.

Could it be that the $conflict field prevents actions like this?

If anyone knows of a work around, I sure would appreciate it.