Rest - MaterialQueueSvc - broken methods? (Object reference not set to an instance of an object)

Hi I am working with the Rest Service and I am building a few things that use the material queue service. Has anyone else found that GetByID and UpdateExt broken on this service?

If I use GetList the method returns several of the material queue items as expected. (see pic)

If I use the GetByID with a known material queue item seen in the GetList picture above. It throws a 500 error. (see pic)

Futhermore the UpdateExt and Update methods both fail to update the dataset when pushing the datarow through with and without the RowMod ‘U’ with the full dataset and all.

I have built several pages with the REST API so its not an issue on how to use it, it is more that the object is bugged. Just wondering if this is a known issue?

I have built a workaround with an updatable BAQ with base processing to bypass the issues.

You should report it to support, it is a bug

1 Like

Any progress? We’re about to finish writing an Auto Picking app to complement Fulfillment Workbench and were going to use this api.


We did report the bug and it may have been fixed in the latest build. Not sure.

I found the workaround for the issue and I have tried my best on a number of other threads to make people aware of this as it occurs on a number of other update methods.

Essentially when invoking Update on certain services you must pass the row you wish to update through twice.

Here is an example of me trying to update a single material queue row.

Initially after getting the material queue row, duplicate it, use the second row ([1]) to RowMod = “U” and use this row to modify. Apply the modifications to the row with RowMod U. When you are ready to update invoke the update method like in the screenshot and pass both the unmodified original first and the modified row second.

As I have stated on a number of other threads I think this works as the internal logic of the update method does a compare on the first row to the second to figure out whats changed.

Hopefully that makes sense, let me know if you have any trouble

Thanks - we’ll give this a try. Actually makes sense considering the work it does with the ice.IntQueOut table trying to reconcile across companies.