After our upgrade from 2021.2 to 2022.2, a few updatable dashboards stopped working. Digging into the Update Processing’s tab for BPM Directives Configuration, we’ve got two BPM’s - a base to make Epicor happy (thanks @hkeric.wci!) and the real update one. Both BPM’s fail for this error. Do I need to add a reference? Or something else? I’m guessing it was a syntax change between versions…
The name ‘queryResultDataset’ does not exist in the current context’
Thanks for the help!
Go in that code window and right click, chose “Parameters?” and what is in there is what you should be using.
Kevin, if I right click in the code window, I get Edit (copy, paste, etc…) or Call Context. No Parameters? option.
I also tried re-running Directive Update per @Jason_Woods recommendation here:
That’s a new one on me!
Shot in the dark. Pull that code out somewhere and store it.
Delete the BAQ BPMS.
Turn off update on the BAQ and save.
Add it all back.
@askulte I would make a copy or just save the code and change update processing to BPM update and then open up the stock bpm to see what it references. I have seen some that are results.Results
He doesn’t have ANYTHING listed, something is messed up.
Hopefully recreating fixes it.
Should look like this:
yes, see what is there in their stock routine after he recreates it. He won’t have to look for parameters their code will show what they are using now.
What I’m saying is, if that menu item does not show up, it is broken. No matter what they are using.
Yes, I got that. What I’m saying is the generated code will tell him what to use regardless of the broken menu.
What I’m saying is, it’s not just the menu. Update on a BAQ is always “queryResultDataset”.
It’s not just the menu.
Wow, that was weird. After re-doing it from scratch and it worked, I tried bits and pieces.
The fix for the first UBAQ was to delete the calculated fields, and re-create them! Very odd. That let the BPM’s compile without errors, and also gave me back the Parameters option in the code window.
Thanks for the help Kevin and Greg!
On the next BPM, I tried deleting the auto-generated ##BASE## bpm’s, turning off updatable, saving, and turning it back on, but it still errored. Although this time it did have a parameters option:
I deleted and re-created the tables, criteria, and joins for the main and 3 subqueries, yet this one still doesn’t compile. I’ll see if I can copy it out of an old environment, and bring it over to our current 2022.2.8.
Not happy that the UBAQ’s broke, for no good reason that I can tell (yet).
It’s probably something simple that someone overlooked in the upgrade process in some
conversion program.
I bet a straight import from the old environment works fine. 
There is an Updatable Query Maintenance that recompiles all of them that we run after the conversion process. I wonder if that would fix them or if that was what broke them.
Kevin - I tried deleting the broken one in LIVE, and re-importing from last year’s environment, but no dice.
Greg - Thanks for that idea too! I just ran ‘Updatable Query Maintenance’, and it still doesn’t work either… Although I noticed that the .Update directive now passes syntax check, but the GetNew one still does not.
Are you missing any Custom user defined fields?
I think the original issue somehow fixed itself… I ended up importing/overwriting the UBAQ from an old environment, which worked. Then re-imported/overwrote it from our current version test environment.
What’s odd is the autogenerated ##BASE## BPM on the GetNew method never compiled. I even tried a new UBAQ from scratch, and that errored out too. For some reason, this (legacy BAQ from years ago) had ‘Allow New Records’ checked, which we didn’t need. I unchecked it, and it removed the ##BASE## BPM on the GetNew method. No more errors.
Shrug…
Anyways, all is good now. Thanks for your help Kevin and Greg!
