Forum Discussion
Jan 2020 multi value Param Problem
I'm not in a position to test on our system, but just curious if you've tried
select * from table where ID = (@ParamOpt)
and if that gives you any different results? I have a vague old memory about parentheses being the proper form? Might not make a difference though...
No this doesn´t solve the issue. The Params were obviosly replaced or inserted via string replace and there is something different compared to old versions.
This is apparently a bug which the product team are aware of and they are working on an updated Jan download. I don't think they have a specific timeline for when this will be available, but they do want to get it out as soon as they can. (so keep checking the date of the relase at https://aka.ms/pbireportserver and see when it changes from Jan 27th)
In the short term the only work around I am aware of is to rename your parameters so the names are not a subset of each other. (eg if you rename param to @Param1 it will no longer "overlap" with the start of @ParamOpt)
d_gosbell : could you check another issue for me? When editing an subscription, where an old user, who left company already and is erased from AD, I get an error message indicating, that the user was not found. Surprisingly I was not able to find any hints, where the user was involved so I´m struggling in editing the subscriptions at the moment.
Any ideas?
Regards,
Thomas
When you edit the subscription check the owner for that subscription. If it is the deleted account then you will have to change this. Any subscriptions owned by deleted or disabled accounts will not run and I don't think you will be able to save edit to these subscriptions without changing the owner account as PBIRS will not be able to validate the owner (this is a security mechanism to prevent people somehow setting up reports to be forwarded to them after they have left a company).
For this reason we usually use special "service" accounts with non-expiring passwords when setting up data driven subscriptions.
