I never said they were good options. 
1 Like
Hmmm I got an idea 
2 Likes
My first thought was, if all else fails get a bigger hammer and split that up over a fleet of API keys. Or just one with ‘allow multiple sessions’. But you’re not SaaS (yet). You might actually have to consider rate limiting!
1 Like
Problem is is the same order, so doing different updates across different sessions gets you the dreaded Record hsa been modified… Cause remember they all update the same ORderHed and ORderDtl
2 Likes
Ouch. What a waste of cpu io and bandwidth
Lazy loading revamp, needed
Here’s a good read on the subject.
1 Like
Thought…
Could you do a post processing BPM to clear the return tableset out?
While this will not stop it from needing to get the data from SQL it will stop it from needing to be serialised / compressed to send to the client.
I would not use .Clear() as that has overhead in its own right. But you could set the output ds to a brand new tableset…
Tries that as well it only improved the transit time which was a couple of seconds
The GetByID runs internally and so it still did it no matter what 
1 Like
2 Likes
Create a Base Processing directive and write all the update logic yourself?
3 Likes
Yes I am strongly considering this it’s been running for 9 hours and done 700 rows
2 Likes
Ugh.
You could write it yourself before it even gets close to finishing at this rate.
2 Likes
At that point you’re basically in the “tiny SQL correction here, rebuild the logic yourself there” stage of the recovery plan… which of course is a terrible idea and absolutely not something anyone should do.
Strangely though it does start sounding quite attractive somewhere around day three of watching DMT reopen releases.
Anyway, this is probably no help at all - just adding my 10 pence.
3 Likes
I’m familiar with the “blue” chain of stores based in or near the Ozarks. 
Our POs are simple…single ship-to (DCs only, not direct to store)…maybe 50 lines tops. I’m just glad we don’t do SDQ with our EDI partners…nightmare city.
1 Like
This system can’t.
But if you made an ERP, it could.
6 Likes
When we had to Mass Assign Reason Codes to Cases at Spartan, it would take days, so I did it via SQL because it was a Low Risk change.
When we imported 1 million parts the Multi-Company Processes would run for days Syncing, and you prayed it didnt fail somewhere in the middle and get the whole IntQue tables stuck.
2 Likes
Jose can we please work together and start a focus group. You have contacts, we deal with this daily at one of the companies, we need so much help with this we are about to do a function study with Epicor and then CSG something to help with this, but it’s not just us…
Any chance you’d like to try doing that with me and any others? What kind of commitment would we need to provide, any success with this in the past or past experience with this?
4 Likes
This happens to us too, because we are make to order and when the requirements change from the customer (which happens often) we have to go modify the job, or change the release dates, or delete them, so many things.
1 Like
We have some large orders too and our customers update their schedules on a weekly basis so although we use Demand to process it is still slow.
We’ve also noticed that the bigger the SO the longer it takes to add to a Pack Slip
2 Likes
Exactly, it’s just all the way around… Linking and unlinking jobs, changing releases, packing, shipping, all of it.
It’s not great and we need some serious help.
I know that there’s enough mfg’s here that are shipping to retail or large number of locations that we could get something started at Epicor. Something we’d pay for. We could all split the cost of getting it developed too, which would be huge.
2 Likes
I feel your pain @josecgomez , i really feel your pain. I am currently migrating 68000 lines of CMI from E9 to Kinetic using PO DMT and it is like watching Paint dry to be honest 
3 Likes