December 5, 2013 at 7:58 am
Hi
i get an error when I show multiple values in the parameter
Do I declare the variable differently in the SP?
...@Code varchar(10)
,@Days varchar(10)
,@Begin VARCHAR(10)
, @End varchar(10)
, @Zip varchar(1000) Zip is the only parameter to accept multiple values..
the where clause is like....
where.....
AND dbo.Address.Zip in (@Zip)
December 5, 2013 at 1:13 pm
Yes, read this article. I had to do learn same thing regarding multi valued params and stored procs. Using the JOIN and then in the stored proc code, use a split string function when values are passed in. something like:
ld.ORIGINCITY IN (select * from [dbo].[fn_SplitStringList](@OriginCity)) Can search for a splitstring function in google, there are plenty of them.
December 5, 2013 at 3:16 pm
Michael_Garrison (12/5/2013)
Yes, read this article. I had to do learn same thing regarding multi valued params and stored procs. Using the JOIN and then in the stored proc code, use a split string function when values are passed in. something like:ld.ORIGINCITY IN (select * from [dbo].[fn_SplitStringList](@OriginCity)) Can search for a splitstring function in google, there are plenty of them.
And you can find the best (no-CLR) splitting function in here: http://www.sqlservercentral.com/articles/Tally+Table/72993/
Read the article and the comments for the best performance and test it yourself.
December 6, 2013 at 7:40 am
What's the error?
When you pass a multivalue parameter you have to do a
=join(Parameters!PraramName.Value,",")
I always forget this step, that and forgetting to make my receiving SP variable large enough to hold all the values.
December 6, 2013 at 12:00 pm
Steven.Howes (12/6/2013)
What's the error?When you pass a multivalue parameter you have to do a
=join(Parameters!PraramName.Value,",")
I always forget this step, that and forgetting to make my receiving SP variable large enough to hold all the values.
Wasn't this a new feature with SSRS 2008? IIRC, there was no other way to do this than splitting the string in the stored procedure with SSRS 2005, so if the OP is still using 2005, he'll have to go that route.
Jason Wolfkill
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply