Hi all

Using the Geist Database transactions method I am restoring stock levels of a single stock line, and then removing the stock ID from the Line Item (which is the parent record). The idea is that I am replenishing the stock, it being no longer assigned to the Line Item.

I am not using a portal, it is just a single related record ('Recurring_Services_Stock'), and the editing of the primary record ('Recurring_Services') must occur after the editing of the stock level (otherwise there is no relationship). For these reasons I believe my script is slightly different to examples Todd gives. Therefore I'm interested to know whether my script is excessive, or insufficient:

It looks OK, although I think for clarity I'd move line 7 below line 10 to nest that 'if' section.

Thanks Fitch. I take it the below is OK then for adding stock? I think I'm unsure about (and I'm really splitting hairs here) is whether I should apply line 54 at the beginning, followed by 55-58, then change the stock levels but based on the 'recurring_services_stock' relationship and not the 'recurring_services_preview' relationship. The latter being based on the recurring_services::RS_Temp_Stock_IDF field.

Not sure it matters or what Todd recommends, but I'd probably attempt to update the parent record first and then the child records. If speed is a concern, do whichever one would fail fastest.

Thanks Fitch. One more thing I've wondered about is why, in the case of performing multiple set fields (upon the same instance, e.g. lines 54-58), you don't need to set the $error variable after each set field, is it not possible that line 54 could produce an error but not line 58 (in which case it would not record the error).

Depends how paranoid you are. If the error you're concerned about is record lock, you only need one Set Field to tell you if it's locked. Alternatively, you could use the Open Record script step to test for the lock.

Keep in mind that it's possible to get different errors for different fields, e.g., someone has access privileges to one field but not another. If you have those kinds of concerns, you'd probably need to test each field.

Brilliant. The number of users accessing such records is very low (if not 1), even if privileges are in place, so I'll leave it as it is for the moment.

Cheers!