Recent posts:
Recent replies:

Probably unrelated, but you most likely do want MSI.IN835.EOBList to have storage.

The reason is that if your BPL suspends for any reason (such as a Call) between the time you set and use that data, you'll lose whatever values you were trying to save.  That's because the job that's executing your BPL will %Save the Context object and go work on another task while it's waiting.  When the Call returns it will reload the Context object and resume work.  If you extend %RegisteredObject your context property won't survive the save/reload.

It might be tempting to ignore that if you're not currently doing any intervening Calls, but things tend to change over time, so doing it now could prevent a hard-to-find bug later.

%SerialObject is probably better that %Persistent for this because that way you won't have to implement your own purge of old objects.

Or, if you only need to store a list of integers, you could just declare your context property as that and skip the custom wrapper class.

The premise is that when you have a timestamp property that’s set at the time of row insert, there will be a guarantee of those timestamps being “in order” with respect to Row IDs.

At first glance that sounds reasonable, and is probably almost always true, but I’m not sure it’s guaranteed.  Isn’t there a race condition around saving the timestamp and generating the new row ID?

That is, couldn’t you have a flow like this:

Process 1, Step 1:  Call %Save.  In %OnSave:  set ..CreatedAt = $zts  (let’s say this gives me 2018-06-01 16:00:00.000)

Process 2, Step 1:  Call %Save.  In %OnSave:  set ..CreatedAt = $zts   (let’s say this gives me 2018-06-01 16:00:00.010)  << +10ms

Process 2, Step 2: Generate new Row ID using $increment, and complete %Save (let’s say this gives me RowID = 1)

Process 1, Step 2: Generate new Row ID using $increment, and complete %Save (let’s say this gives me RowID = 2)

Is that likely?  Definitely not, but I don't think it's impossible.

Actually, it might be fairly likely in an ECP environment where multiple ECP Clients are inserting data into the same table, one reason being that system clocks could be out of sync by a few milliseconds.

Does that make sense, or am I missing something?  For example, would this all be okay unless I did something dumb with Concurrency?  If so, would that still be the case in an ECP environment?

Okay, thanks for updating.  That error didn't seem to make sense based on what you showed before.

This very simple BPL might help you see how to declare and use a List:

<process language='objectscript' request='Ens.Request' response='Ens.Response' height='2000' width='2000' >
       <property name='MyList' type='%Integer' collection='list' instantiate='0' />
<sequence xend='227' yend='451' >
        <assign name="Append 1" property="context.MyListvalue="1action="append" xpos='278' ypos='291' />

Note that I don't need to initialize my list property.  That will happen automatically.

Also note that I'm using action='append'.  That will insert the new value to the end of the list.  It corresponds to this in COS:

do context.MyList.Insert(1)

BPL also has action='insert', but that inserts into a specific location.  It's equivalent to InsertAt for lists, or SetAt for arrays.

Clayton has no followers yet.
Clayton has not followed anybody yet.
Global Masters badges:
Clayton has no Global Masters badges yet.