In what order are the customer updates in an update set applied?

[spike]

Pretty much as the title says, "In what order are the customer updates in an update set applied?"

What field is used to order them?

I am experiencing an odd problem where customer updates appear to have a different sys_id for the object they are updating (say a catalog item). I suspect it might be related to me being told to remove the DELETE statements from my update set (I'm creating a catalog item via the catalog builder and capturing all the updates in an update set.)

So to try and understand what's happening, it would be helpful to know the order in which the individual updates (INSERT_OR_UPDATE and DELETES) are applied.

Thanks!

[Daniel Draes]

unfortunately, last time I checked the have no order at all. It is basically random. If an INSERT_OR_UPDATE and a DELETE of the same object are in the same update set, you don't know which one will win. It could actually be different on different runs/instances.

[Allen Andreas]

Well, if you have a field that you've added to a table and that's captured in the update set, then you delete it and that too is captured in the same update set, and then you promote that update set and subsequently commit it, the field doesn't exist on the other instance?

I would imagine that it more so goes with the date/time on the customer update itself, which is also used for collision checks, etc.

So the INSERT_OR_UPDATE would obviously exist before the DELETE, so the INSERT_OR_UPDATE does process first, then the DELETE (obviously you wouldn't need either of these in your update set to begin with, but the point was that it shouldn't be random).

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Daniel Draes]

I do agree that this would be the expectation - reality proved to be different for me though. Hence a best practice I kept telling so far was to keep creates and deletes in separate update sets.

I would need to do some further testing since my experience with it is about 4 years old. Since than we added quite a bit of functionality around source control and application packaging, which probably had a good influence on the handling of these when it reaches a target instance.

[spike]

Thanks for the comments.

How odd though. I really can't imagine that it's random. That would just make no sense. I'd expect the update set to be worked through in order of things captured. Doesn't make sense otherwise! What if something in your update set is dependant on something that has been created earlier? If it's not applied in order then the dependant update is going to error surely?

EG I create a new category. I then create a SR in that category. If the update set doesn't create the category first, then the SR is going to error.

There must be an internal order somewhere? Now whether we, as users and developers can access it, that is another matter!