I’m not optimistic that Epicor has a solution for this issue, but I wanted to see if anyone else has run into it.
I’m working on an implementation that will result in more than 1,000 UD100A records being associated with a single UD100 header. While testing, I discovered that when I update (and presumably add) a record through this API call, the response includes both the UD100 header and all related UD100A records.
My UpdateExt calls are wrapped in functions, so client-server bandwidth should be minimized. However, I’d prefer not to query all of the associated UD100A records from SQL just to perform an update.
Has anyone experienced this issue before, and if so, found a good way to work around or resolve it?
Short answer no, the Epicor BO’s work that way and have worked that way forver, since you are doing all the work server side function anyway it shouldn’t be too bad.
One option since its a UDXX table is to use Db context to do the updates instead of the BO. But this is only an option since its a UDXX table. Handle with care
Thanks, I was afraid it would be something like that. I was aware of the DB context solution but am avoiding it for now because of the risk. I can access again, once it gets slow.