Vitaliy,

Thank you very much for the working sample - I really appreciate it!!  In the end I decided to go with the approach of just projecting the property from the container into the embedded obj because it ended up being better for my particular project.  If I have to revisit this in the future because I need more than just that one property, I will definitely try out your example!

Thanks again,

Ben

Thank you all ... sometimes all it takes is a good night sleep :)

I figured out to avoid recursively updating the value via the trigger .... don't update it if I don't need to :)

Here is my code - it now works like a charm!

Trigger TUpdateFoobar [ Event = INSERT/UPDATE, Foreach = row/object, Time = AFTER ] 

  {

    Try { 

      // get value of Foobar 

      NEW fb 

      SET fb= {Foobar} 

      // INSERT value into embedded foobar, *only* if it differs from Container value

      If (fb'={InnerObj_Foobar}) {   

        &sql(UPDATE ContainerObj (InnerObj_Foobar) 

            VALUES (:fb) 

            WHERE %ID=:{ID})           

        }        

    } Catch tError {             

      Do LOG^%ETN             

      Throw tError        

    }

  }

I have been trying this approach but I am hitting a wall. It appears that because I am inserting the value into the embedded object in the container, it is seeing this as an additional UPDATE and calling the TRIGGER again, resulting in a <FRAMESTACK>.  Any ideas on how to prevent the <FRAMESTACK> error? 

Here is my simplified code:
 

thank you for the time you took to look!  I thought that UPDATE SQL rights might be sufficient.

Thanks again and have a great night!

Agreed - this could be very dangerous if not used carefully.  Fortunately in my case it's a training VM where all users are created programmatically :)

Do you have any idea on the minimum privileges required to select or update the Security.User table?

Thanks again for your help!

This is for an exercise I'm creating for updating users via SQL.  It is for educational purposes only and isn't going to be anything used in production

Thank you Gilberto!

Any idea what resource is required to do this?   Is it just granting UPDATE rights on the Security.Users table?  Or is there a DB Role (limited - not %All or something crazy like that) which will allow this to be run?

Ben