OK, maybe I’m not that new to BAQs. But I feel silly to have never asked this.
Is there not a way to declare a variable or constant in a BAQ?
Yes, I use parameters, but it prompts the user. I don’t need that.
The most ideal use case would be to grab a value from a table, store it as a variable, and then reference that instead of querying the table thousands of times.
Here’s a simple example of this. To grab some data from PartDtl, I want to exclude forecast data per the company configuration settings (+X days and -Y days). The way I do this is to join on JCSyst (Company = Company) and then filter PartDtl per those settings. (Or I could have put that in the join itself.)
But all I really needed to know is that it’s +30 and -0 (or whatever).
But even for something simpler than this, like a truly static value that I use in 5 places in a BAQ, like [today - 30 days], I might want to make that [today - 60 days] and now I have to find the 5 places I set that value. Sometimes I do that repeatedly to test something.
I’ve done this via a subquery and a calculated field, then just join in the subquery (doesn’t need to be a complex one) on company or something and display the calculated field which outputs your constant.
Like a subquery on Company (for the current company) - thus having only 1 record - and then a totally bogus calculated field for the sole purpose of being a constant.
Neat - I hadn’t actually bothered to try that before. That’s going in the memory banks.
But this means you are saying there is indeed no simple way to just set a constant of ThisNumber = 7. Right?
Not to my knowledge, but I bet you could via the use of the “run BPM designer” too to set global execution level variables. I like the subquery approach since it’s easy to maintain your global variables in 1 subquery and those apply wherever you want
I do like all the alternate ideas, don’t get me wrong. I’ve put a total of zero effort into this problem before, so I appreciate the advice. Lots of tools for different uses.
But does it not strike anyone as a tad absurd that you can’t have a non-prompting parameter, basically?
I just used a single level for an example, but no reason you couldn’t make it a subquery. Or even just leave the calculated field in your top level. You’ll just have an extra column. You can ignore that.
You might have to play with the syntax, but you should be able to. If you are using it in different levels, you might have to do level.field to get it to work.
Worst case, you just drop the sub query into whatever level you need it. Then it should be available. (you don’t need to join it)
