Using the erp-selection-list control to build a list of filter values. It allows to set a delimiter but that seems to be ignored, it’s alway building a ~ delimited string. My thought is to use a row-update to swap out the ~ with a comma and then pass that into the Having bit of the where clause when I execute the BAQ using the erp-baq action. I was trying something like this
(‘??{TransView.tvChartList}’).replace(‘~’,‘,’)
As I suspected, doesent work and not finding much syntax help.
I wound up using a function to do this. When dashboards are converted Kinetic apps using the classic dashboard tool, it wires the execution of the underlying BAQ to an invalidate action. This is really noisy, running the BAQ many times when its not needed.
1 - I broke the binding to the BAQ on the grid and wired a button the run a BAQ action.
2 - I created a function that takes in a delimited string, a source delimiter and target delimiter.
3 - In the button click event, I pull the value from the selection list field that I have bound to TransView and pass it into my function.
4 - The value coming out of the function is captured in another system data view that is similar to TransView called actionResult.
5 - I then call my BAQ passing in the comma delimited list and get the correct results.
I know you already found a solution but for posterity, here’s the syntax.
I don’t believe you can use the ?? notation in a row-update, so you may want to check for null with a condition before the row-update.
'{TransView.ReplaceSource}'.replace(/~/g,',')
Worked perfect Hanna. This is an excellent alternative.
‘{TransView.tvFromString}’.replace(/{TransView.tvFromChar}/g,‘{TransView.tvToChar}’)
We found an even better solution that does not require string replacement if your using it just to filter and aggregate. Even though the selection list control is using a ~ delimiter, you can pass that value into a BAQ parameter and create a calculated field that populates based on this SQL expression in the calculated field editor.
SUM( IIF(CHARINDEX(CONVERT(nvarchar, GLJrnDtl.SegValue1), @YourParmHere) > 0, (GLJrnDtl.CreditAmount - GLJrnDtl.DebitAmount) , 0) )
Interesting. That’s only for ~ delimited though, right.
The delimiter doesn’t matter. It is going to look for an exact match for Segval1 in the string that is passed into the parameter.
Example
SegVal1 = 1470
Parm Value = 1223~1665-1220,1470_6780
If it finds an exact match, it resolved to true and sets the value.
Then you have to be careful of exact match to a partial.
If in your example, your Parm value was instead:
Parm Value = 1223~147089.1665-1220,1470_6780
Would it pick up the first instance, instead of the actual exact match?
Yup!
This is kind of a buyer beware solution but you have the idea. As long as your parameter string is structured to accommodate the target you are evaluating, you shouldn’t get unexpected matches.
@Mark_Wonsil IYKYK 
