You can release an engineered job, yes. Not sure what the other allowed changes are but that was the one I was after.
I suspect there is a disconnect between the REST service end point interacting with the BO and the screen interacting with the BO. UpdateExt works so it’s not the end of the world.
Unfortunately (or fortunately depending on how you look at it), we’ve decided that this needs to be left on.
How did you create / populate the “UpdExtJobEntryTableset” that the UpdateExt method takes, as opposed to the JobEntryTableset that the regular Update() method uses?
You don’t really populate an UpdateExt dataset, with a BO. You populate all the key fields, and your
changes, and it in theory should handle the rest for you. (Sometimes it’s dumb.)
What that means is, add just your changes and all of the required fields with code or widgets, and
let it fly.
Here is a good post for you:
OK I see how to use it through the widgets. However I now get the following error:
There is at least one compilation error.
error CS0433:
The type 'JobHeadRow' exists in both 'Erp.Contracts.BO.JobEntry, Version=10.2.700.0, and 'Erp.Contracts.BO.MassIssueToMfg, Version=10.2.700.0
Bah. The only way around it for me so far is to change a setting in Company Config regarding “engineered and prevent changes”, then I don’t need to try this UpdateExt to force release on an engineered job. Also, can’t use JobEntry.UpdateExt() method in this directive because I am already using the MassIssueToMfg BO which contains the same tableset names I suppose. SOL! Haha.
There are ways around that. I’ll hit you up later.
I would love to know how to get around that because it has hurt me more than once! And my client is not OK with changing the company setting for engineered and prevent changes on jobs so I’d love to figure out a workaround.
For anyone snooping on this thread / issue, I was able to get around the error regarding the same named tableset(s) / row(s) in 2 different business objects by not adding the second BO assembly in the “usings and refs”, and instead declaring the Svc Contract and Tableset with the full path(s). At least I am 99% sure this is why it worked. Only other change was that I moved the code to a new “Execute Custom Code” widget before the code that’s using the MassIssueToMfg BO instead of putting the code in the same widget…
That worked because the method had them referenced already in the background.
Like any method on the JobEntry BO, will have the JobEntrySvcContract etc already referenced.
Many thanks to everyone who participated with this thread. Literally started with the top issue, hit every issue on the way down.
Ultimately solved each issue. Duct tapes helps. And so does the advise.