Still hung up on this:
I understand that’s the way it is cuz legacy but wonder…
Couldn’t we just stop passing the before image back and instead, in a preprocess directive, hydrate it serverside from db using SysRevID?
To prevent write conflicts with other users.
1 Like
you could not do it with UBAQ - there is no way reliable know what row is returned by arbitrary query.
1 Like
SysRevId alone can do that.
I don’t follow sorry.
my point is that you cannot always get correct data by SysRowID. One issue with concurrency as ALisa mentioned, another issue when your data are not from one table but from several, like in BAQ.
1 Like
meaning because another user made a change? In that case, mine is always blocked, correct? So before image is useless.
It should not be used in the modern world as it is for sure, that I agree.
2 Likes
The ‘why?’ question was rhetorical. My real question is can we get around it using preprocess?
What are you trying to get around? Specifically? What’s the issue at hand.
1 Like
nothing really just waste over the wire. curious why not to rehydrate server-side if possible.
That makes any change to the record give the “Record Updated by Another User” messages. In some other ERP systems, I’ve seen the record segmented. So, if I print the record, the date printed doesn’t block other updates since last update wins. Other changes are critical to timing and any changes in that segment would block. I don’t recall exactly how that was implemented though. Something about a hash on that section on read and then compare the hash for that section before update maybe…
2 Likes
OOOOH! Light bulb moment! Thanks Mark. Of course! I’m used to ETags. These are hash-like values which include only field values the service determines should block concurrency. SysRowID is no such thing.
1 Like
It was just an architectural issue from Progress. They would absolutely not do it this way today if they started from scratch
2 Likes
Thanks. I get that part. Was hoping rehydrate serverside might work to avoid the waste and also simplfy an API app by avoiding the before image song-n-dance.
1 Like
)
Ha. I can never remember so I guess every time. Except this last time when attempted to refer to the experts.
But if they did it differently, would they be making Progress? 
6 Likes
Yep, this is exactly what PATCH is for. Instead of round-tripping the whole row, send only intended changes (JSON Patch RFC 6902 or Merge Patch RFC 7396). Then the server knows which fields were modified without doing a full “before image” diff. Because you only ever send modified fields. (And the Primary Key SysRowID)
Epicor’s UpdateExt kind of resembles this, but because the BO layer is still built around dataset state + Change/After hooks, it often has to reconstruct a full row and run the whole rule pipeline anyway, which is where things get messy. (And often don’t work too well)
Combine this with Optimistic concurrency around SysRevID and you got yourself a winner. But it would require Epicor re-engineer all their BOs
5 Likes
What we have works good enough that its understandable that this hasn’t been done.
But if you were starting over to make a cloud first, browser first ERP system instead of pushing and old system beyond its design . . ..
8 Likes