UBAQ Update() queryResultDataset.Results Contains Only Modified Rows

So, I am stuck on something for a project I’m working on, and I did quite a bit of online research for an answer but I am not finding any specific details on this one particular feature of UBAQ’s.

It basically boils down to this: I’m confused why it is that when I place code on the Update() method of a UBAQ and run some tests, the only rows contained in the “queryResultDataset.Results” are the modified rows. Meaning, only the unchanged and updated versions of the rows which the user has modified by playing with one of the updateable fields.

So for example, if I update an updateable field on a single row in a table of 1000+ rows, then run Update()-- when I try to then loop through not only the modified (updated) row(s) but also all of the unchanged rows (including rows which have not been modified at all but that are in the designer results grid), the only rows available to access in the “queryResultDataset.Results” are only the modified row(s). So in this example, only 2 rows exist in the results in the BPM, that being the single unchanged row and the single updated version of that same row.

The unchanged & updated rows both being there are as expected for me, but what I am confused about is-- where are all of the other rows which are in my table before I run update?.. They seem to disappear in the Update() method “queryResultDataset.Results” parameter. However, I’ve been able to access these rows in the RunCustomAction method Results parameter. Do I need to access the complete list of rows (including non-modified rows) some other way when coding on the Update() method in a UBAQ?

Thanks for reading :sunglasses:

Edit: I marked my own reply as the solution since it outlines what I ended up having to do in my specific case-- but, for the future lurker who might have a similar (but not identical) issue or use case for this knowledge, basically in most cases you can do like @gpayne said and access the full table results (as displayed in the the grid) via post on GetList(), or you can access them in Pre also on RunCustomAction() granted no rows have been manually modified; in which case like Update() only the modified rows will be included in the Results parameter.

1 Like

In case this illustrates the question better, here you can see where I updated a single row in a results set of 3800 rows. The Results table in the Update() bpm contains only the unchanged and updated row states of the single modified row, none of the non-modified rows.

1 Like

if you want to hit them all do it post processing on GetList.

2 Likes

I understand I can access them all on GetList. But I specifically need to do something (if possible) during the update process, or I will resort to some custom code in a dashboard customization worst case scenario.

One other option I have is if I can emulate the user modifying (updating) rows via a custom action, then when Update is ran, it would see all of the “modified” rows with their respective rowstates. I haven’t been able to successfully do this via Custom Action yet either.

1 Like

Then just run GetList before your update and get all rows. Or just access the records directly from the table. What are you trying to do exactly?

3 Likes

This is just how it works.

Why don’t you step back and give us the whole picture.

Maybe we can advise you better.

4 Likes

Hey thanks for all the replies guys, it sounds like update method just doesn’t have access to the full table and that’s that, unless you re-run the BAQ in the method (I did this in some other cases) but that doesn’t guarantee the results are the same as what was displayed in the table. Not the end of the world, what I ended up doing last night was setting up a custom action that, as long as the user hasn’t modified any rows yet, has access to all of the table rows and runs updates conditionally to some PO’s depending on the values contained in a handful of UD Fields on the rows in the current results table.

Basically what I was trying to accomplish was one way to do what a user specifically requested functionality wise, without the need to do it through dashboard customization script so I could keep all the development in the UBAQ(s).

The ask was a button or custom action that would go through and check a certain updatable checkbox on all the rows in view if desired, then other updates could be made if needed before running update finally.

I used a custom action to just perform the actual update on all applicable rows in the table instead of just checking the box, so its a similar end result but just slightly different than the requested functionality. I may end up using a custom button with script in the dashboard after all depending on how it works when this tool rolls out. I really do appreciate the input / insights, I wasn’t sure if maybe there was a variable or parameter I just hadn’t discovered yet in the update method that still contained all the rows.

2 Likes

Your custom action should be able to make the changes on the data, then if you want “update” to pick it up when you actually save, you might need to toggle the row mod in the custom action. So use custom action to set any data you want in the grids first, then call update to commit the changes.

Mess with the row mod, and updated fields on in the custom action. The UI, probably for performance sake, only sends updated rows back to the server. Otherwise it’s a ton of overhead for usually no work to be done.

image

image

2 Likes

Yeah- I agree in most cases it wouldn’t be needed so it should perform better without it etc.

I did try this and played with the RowMod values and SetRowState() method but nothing was able to actually “trick” the designer and emulate a user double clicking a row to modify it. I was able to modify updateable fields via the custom action as normal, but was not able to actually get the rows to go into an updated state that would be recognized by the designer unless I double clicked the rows, even though the row mod / row state was set and the fields were changed.

I also tried “adding” the updated version of the rows to the results, leaving the unchanged row as-is like the datasets look normally, so you have the unchanged and the updated row states, but that didn’t work right either. I’m not sure you can emulate the modified rows in the grid like if you actually double click a row (or in a deployed dashboard you have to modify an updateable field value to get it into the modified state vs double click).

Have you thought about using code in the dashboard itself to mark the rows dirty?

1 Like

Yes-- that is a for sure workable solution. I ended up not really needing to do it for now since the Custom Action will suffice. But yes that would work, I just want to avoid having to add the development to the classic dashboard itself since I am going to have to recreate this thing in Kinetic in the coming months anyhow, and I wanted to keep as much of the development in the UBAQ’s and functions for now. I may, down the road, eventually go the route of a custom button in the classic dash customization to dirty the displayed rows.

1 Like

I just want to add that you guys rock! Thank you so much for trying to help me on this one, this forum is such a great resource and I’m super grateful for y’all. I wait to post a topic until I’ve tried everything I can think of or find online first. Thanks for putting up with my super specific pain-in-the-butt topics :alien:

3 Likes