Create a new Object using ST

[BevanWeiss]

Hi all,

I really thought I'd done this before, but I can't find any example of it in my at-hand databases.

I'm looking to automatically create Operator Document Stores for User accounts that don't already have them.

I know that this could be done using a couple of SQL queries to INSERT a new row into the Operator Document Store table, and to then UPDATE the CDBUserViewXConfig table with the new OperatorDocStoreId.

But I'm not a huge fan of the SQL form here.  I'd much rather something like CGroup.CreateNew("Operator Document Store", "freddie");

Am I just delusional that this would be possible using a Method or similar from ST?

[sbeadle · Accepted solution]

Hi Bevan,

there's no exposure of the COM or .Net Client style methods to create objects in Logic. If it were that easy I can't imagine the follow-on problems it might cause! 😀

Steve

[AdamWoodland]

Could use SYSTEM() to call some app or script on disk is another option

[BevanWeiss]

Lol... I'm creating objects via SQL from ST... is that better @sbeadle ? 😛

I think it would have been 'cleaner' if I could have called like a 'Create( 'TypeDesc', 'Name' )' method on the parent group from ST, and just passed in those items.

Even better of course if it would return the ID of the newly created object... then I could easily update the OperatorDocStoreId 🙂

That is some bold out of the box thinking from @AdamWoodland on the SYSTEM() command idea though 😮

I very much dislike it however, and I think I do prefer my SQL ST calamity.

[AdamWoodland]

Logic is too disjoint from the database for that, property writes and %D SQL execution happens long after the logic has finished executing. During the execution they are just put onto a stack.

The logic process is documented at https://community.se.com/t5/Geo-SCADA-Knowledge-Base/Logic-Execution/ba-p/279061

I figured you might not like the SYSTEM() option, I wasn't too keen on that idea myself but how good it might work is very customer specific 🙂

[BevanWeiss]

Hi @AdamWoodland,

I was thinking something like the Expression engine Method Tags, where a Method can be called which returns a result.

You're right, that it wouldn't really work with the INPUT>PROCESS>OUTPUT structure of the Logic engine however.

I could probably do it using a second ST Logic routine, and indirect addressing... but then I'm tying together an SQL INSERT (called by ST logic) and the calling of a second ST Logic routine... I'm not sure entirely how the timing around these would be performed.. so I think it's probably less risky to stay in either SQL or direct ST output manipulation and not do a little of both..

You did make me read about the NOCACHE stuff again, and I forgot that they can apply for normal Input data as they can for SQL inputs.  I'm sure I can find some more places tomorrow to go sprinkly through NOCACHE references...

My next problem around the Operator Document Stores is regarding the security permissions, and the need for CFG... (and I guess more annoyingly having to break the security inheritance).  It would be nice if security could be implemented as a 'delta' type of operation without breaking inheritance... i.e. I want everything just like the ParentGroup.. except ADD CFG for this person.  or SUB CFG for this group (if it did have CFG from the parent).