I am creating a Stored Procedure that will be used as the Data Source for a Crystal Report.
The Stored Proc takes two input parameters - int and a comma delimited string list
Create procedure sp_AP_YTD_Payments1
#Year as int,
#Companies nvarchar(MAX)
as
-- SP code here
I do realize that I will have to convert the string list to an array before using it in the where clause.
I have two questions :
How do I pass the parameters to the SP using an exec sp_AP_YTD_Payments1 ?
From Crystal Reports, how should the user enter the second argument ? As a comma delimited list?
I found the answer myself.
exec sp_AP_YTD_Payments1 2013, '925,926,TXR'
From Crystal, the user will enter a comma-dlimited list for the Companies parameter.
There is a better way to handle the second parameter. If you are not using subreports you can move your report to a subreport, create a multivalued parameter in the main report and pass the parameter values to the subreport using Join function. This will allow your users to select the values from a list and to not care about the coma formatting.
This article for multivalued parameters in stored procedures might be helpful:
http://www.r-tag.com/Pages/MultivalueParametersWithSQLSP.aspx
Related
I am trying to find a way to write a stored procedure that will take a list of nvarchar's as an input parameter. There can be one to finite amount of items in the list.
I also am not sure how to call a stored procedure from C# as a list, I am use to using data types like int or string.
Stored Procedures are being managed by Sql Server 2018
I have in my report a few needed arguments like 'A','B','C' and I would like to pass it using SQL.
How can I do that?
I tried prm_szDiscType='C','N','P' , prm_szDiscType = C,N,P, and prm_szDiscType=''C'',''N'',''P''
I'm not sure how you pass parameters via URL.
In Crystal Reports desktop client, I created a Command Parameter with "Allow multiple values" check on.
Then in my Command SQL, I use a where clause such as:
where item in {?Item}
When you check "Allows multiple values" on, Crystal will create the clause after in. If you select Value Type of String, the values you enter will automatically be wrapped in single quotes.
Credit to ExpertsExchange thread on command parameters ;)
I currently have a report which feeds off a stored procedure with the parameters being two date fields i.e. dateto and datefrom.
Now within crystal report and not sql I have created another parameter which asks for the option to select the company the employee belongs to, this can be multiple option or not.
My issue now is that when I run the report the first parameter prompt I get is only the stored procedure parameters, once I input these values another parameter window appears asking for the stored procedure parameters again i.e. the dates but this time also the company parameter.
Is it possible to only have one parameter window prompt with the dates and company parameter appearing once and having to be entered once ?
You can check two aspects：
There is no subreport in this report.
Option "Verify on First Refresh" and "Verify Stored Procedures on First Refresh" are unchecked.
I would want to add an optional parameter to my stored procedure with default *. If the list of columns is provided [delimited by a comma] these columns should be returned back by the procedure. If the wildcard character is provided [star] *, all columns should be returned. Please let me know how to implement it.
First thing - why stored procedure not table UDF?
Anyway it would be easier to pass null instead of "*" - tsql allows default values on UDF parameters.
You would have to construct query dynamically and then use sp_executesql().
The issue is that you should validate columns list to prevent errors.
I am developing an SSRS 2008 report, but instead of using stored procedures, I want to use all Text queries. This report was working with stored procedures, but when I changed this report to use same logic but via text queries, I got the following error:
An error occurred during local report processing
Query execution failed for dataset 'BRSR_Totals'
The variable name '#END_yEAR' has already been declared. Variable names must be unique within a query batch or stored procedure.
Operation cancelled by user.
The problem is that some of my datasets (text queries) re-use the same parameters and END_YEAR is one of these parameters. How do I make this report run correctly?
One area that you might want to check is case sensitivity. SSRS is case-sensitive when considering parameter names but T-SQL does not have that case sensitivity. Take another look at your code and make sure that all parameters are using the same case.
I just resolved a similar issue using a text query to populate a dataset. It worked in SQL Server Management Studio and it worked in the Query Designer within BIDS, but failed at runtime.
The issue turned out to be BIDS helpfully adding parameters to the Dataset that this query was referencing. Switching to the Parameters tab of the Dataset Properties showed that BIDS had duplicated the parameters I had already added earlier. Deleting the duplicates resolved my problem.
To respond to the suggestion that the logic be off-loaded into a stored procedure: in this case, the report is a custom report for a single customer. The query will only ever be used in this report and makes a few assumptions about the customer's configuration that should not be available globally
I also just fixed this same issue in one of my queries. I was using a text query and had datetime variables/parameters. SSRS added a second set into the parameters for the dataset properties. I deleted them and my query ran fine after that and my graph populated.
I ran into a similar issue on a report where I had declare a substantial number of parameters at the beginning that I didn't want the end user to see. The issue I had was I was using a comma at the beginning of the line, so I had:
DECLARE #Parameter VARCHAR(4) = 'text'
, #Parameter VARCHAR(4) = 'text2'
It worked just fine in SSMS, but when I ran it in Report Builder 3.0 it threw the error shown in this thread. I changed it to remove the comma and to restate DECLARE at the beginning of each line and it worked perfectly.
Check that you didn't declare it twice, once in the CREATE PROC statement you're creating and another in the actual code...I've seen this problem while testing changes to SP code.