I have noticed that for both EmpBasicSvc and POApvMsgSvc I need to call UpdateExt and not Update in order to save. Anyone else notice anything similar?
When I call either one I get a return HttpStatusCode.OK but Update does not save the changes.
I have noticed that for both EmpBasicSvc and POApvMsgSvc I need to call UpdateExt and not Update in order to save. Anyone else notice anything similar?
When I call either one I get a return HttpStatusCode.OK but Update does not save the changes.
You can’t use the standard OData PUT / POST? Instead of custom methods?
I didn’t try to use the OData PUT/POST, I was more familiar with the custom methods so I went that route. I’m guessing you are recommending the use of OData when possible?
Yeah that’s the way I’d go unless you can’t do it for some reason.
I don’t know if this directly relates @tkoch, but we noticed in going from 10.0.700 to 10.1.500 that in quite a few of our service connects we had to change the Update
methods that were being called when saving stuff (i.e. switching between Update
, UpdateExt
, and/or MasterUpdate
(or is it UpdateMaster
? Well, you know what I mean)). We figured this out because we were getting errors on the save (Update) that were a little hard to explain or figure out, so we just went back to the original process (e.g. creating a quote, or adding materials to a job) and ran a Trace on it in Epicor and observed that the Epicor client is now (was on E10.1 too maybe?) calling a different Update
method than the one in our service connect. We switched, and things were happy.
agreed, exactly the reason i moved away from updateext. Trace is King
Agreed - trace is king!
We have the core methods for standard processing - and it should work or log a bug - but we are trying to make things faster so will throw a curve ball at you and use the UpdateViaAFastMethod() once in a while.