I have a CR 2008 report reading from SQL Server 2008 R2 that used to contain 3 parameters and worked like a champ. The business requested the addition of a fourth parameter. I added the variable to the stored procedure, tested and got the results I was looking for. I then created the parameter as a static list of values as we do not need all values available. I went to the record select expert and lined up my parameter with the appropriate database field. Ran the report, got an error on an incorrect amount of parameters. Refreshed the database; the report ran but returned no results. Checked my parameter values against the stored procedure. Once again, the stored procedure returned results. Went back to Crystal and viewed the query. Lo and behold, the query is sending in NULL for the new parameter even though a specific value was chosen on the prompt. I even went so far as view a tutorial on adding parameters to be sure I did it correctly. Anyone have any thoughts on why the parameter isn't being read properly?
I think you need to right click on Database fields from Field Explorer > Database expert > see this picture
that will surely work coz sometimes crystal reports stored procedure need to be reset or refresh to reflect any changes on the SQl code
Related
Looking for some help with this as me and my 'Mentor' are having some issues with resolving the problem
I have a stored procedure in SQL Server 2016 that works fine when dates are entered. However I need an Excel sheet to execute the stored procedure, which currently is also working fine.
The issue is when I'm trying to use a parameter with Excel to pass through the dates to the SQL query/stored procedure that I need to bring back. I'm struggling to link the two up to each other
The second answer here by mono código > how to pass parameters to query in SQL (Excel) - should work for me, however when I get to the part which explains 'The code in the next section assumes that you already have a parameter in your query (Connection Properties->Definition->Command Text) in the form “WHERE (DB_TABLE_NAME.Field_Name = ‘Default Query Parameter')” (including the parentheses). Clearly “DB_TABLE_NAME.Field_Name” and “Default Query Parameter” will need to be different in your code'
I'm unsure if this is due I just simply do not know how to write this part, or it's to do with how I'm trying to link up the cells within excel to the parameters within SQL
For some more context, the parameters are dates - to and from, which will be in an excel sheet, which will then feed through to a query, which is where the execute code for the stored procedure is.
If any help or guides or walkthrough's could be given I'd very much appreciate them!
Thanks,
Wil-Liam
I have set up a report in SSRS which drills through to a 2nd report. The data in the second report is a stored procedure that has a parameter declared, as in:
CREATE PROCEDURE [dbo].[Procedure] (#Parameter VARCHAR(max)) AS.....
In the first report I have set up the Action on the text box properties to run the second report using the relevant parameter from the first report.
I am designing this in Visual Studio and when I 'Preview' the report in here it works correctly and the drillthrough passes through the parameter as intended. However when I deploy this onto our server and try to view the report using Internet Explorer the drill through doesn't work, I get an error saying that the parameter is read-only and cannot be modified.
From reading other posts relating to this online people have mentioned changing the parameter visibility to 'Visible' however this hasn't worked on mine.
Has anyone else experienced anything similar to this before?
Thanks.
This seems to be a common problem when passing a parameter to a subreport. Have you seen this solution? http://saiabhilash.blogspot.nl/2012/05/report-parameter-is-read-only-and.html
Recently I noticed that a stored proc we are trying to profile failed to appear in the profiling output.
After adding in SP:StmtStarting and SP:StmtCompleted events, I noticed the TextData reported as
-- Encrypted text
.. but the stored procedure is not encrypted.
This has only recently started happening - we used to profile this SP perfectly fine, and I can't figure what has changed.
Any suggestions would be gratefully received.
UPDATE: The SP is definitely not encrypted. I've created new SP's on the box, and I see SP:BatchStarting event with the new SP's name. With the old SP, I don't see the BatchStarting event, but I do see the statements within the SP executing.
However I need to see the values of the parameters the SP is being called with, as they are table types. Originally I could see the table types being instantiated and populated before the SP is called.
So I figured this out in case anyone finds it useful.
I have table type parameters to this stored procedure. One of the parameters is passed a lot of data (i.e. a C# DataTable with >5000 rows). Without this quantity of data the stored proc profiled fine.
I guess there must be some cut-off at which point Profiler does not show all of the data being passed in.
Someone has altered the stored procedure and added the 'WITH ENCRYPTION' hint, which will cause this behavior. Alter the stored procedure and remove that hint and you'll start seeing the text of the proc again.
Also to note, if you don't have the original code, you will not be able to decrypt the text of the proc to issue the ALTER statement, so hopefully you have that handy.
Here's a decent run down of this option: Options for hiding SQL Server code
Moving the Trace Properties from the default of OnlySP(<your database here>)(user,default) to TSQL or TSQL_Replay unveiled the SQL being used for me, ... Go to File|Properties... and change the [Use the template:] drop-down combobox.
I'm working on a series of reports which need to be shown in two languages so I've created a common header that I planned on embedding into the content of each report. I have two data sets, one that looks up a set of strings in English or French (depending on a parameter passed to the report), and another with numerical data.
The original header worked fine and when I extracted it into a separate report it also runs fine. I am just passing the name of the report to the subreport. When I run the main report, it seems that the values in my string dataset are all null (I've tried all of them) yet if I try data from my numerical dataset, the fields have values and get displayed as the title.
If I also insert a text field with the same expression to display the report title after the subreport, it works fine but the title still does not get passed to the subreport.
I cannot make any sense of why this would be happening, anyone have a clue?
I'm using Report Builder 2.0 and SQL Server 2008.
Thanks!
Alright, so I worked around this issue by simply passing my parameters on down to the subreports and letting them call the stored procs again. Not ideal since I now have to call that one stored proc 3 times but it probably won't be noticed.
I tried several other work arounds and received errors like rsAggregateInCalculatedFieldExpression, so my best guess is that this was caused by attempting to use an aggregate function (First) where it is not allowed but the error was never shown.
I am generating a report that contains the version number. The version number is stored in the DB and retrieved/incremented as part of the report generation.
The only problem is, I am calling SSRS via a web service call, which returns the generated report as a byte array.
Is there any way to get the version number out of this generated report? For example to display a dialog that says
You generated Status Report, Version number 3
I tried passing in an output parameter and setting it inside the storedproc. Its modified when i execute it in sql management studio, but not in the reporting studio. Or atleast i can't seem to bind to the modified, post execution value (using expression =Parameters!ReportVersion.Value).
Of course, I could get/increment the version number from database myself before calling the SSRS webservice and pass it along as a parameter to the Report, but that might cause concurrancy problems.
On the whole, it just seems neater for the storedproc to access/generate a version number and return it to the ReportingEngine, which will generate the report with the version number and return the updated version number to the WebService client.
Any thoughts/Ideas?
Since I can't add a comment yet...
Just throwing this out. Maybe render the report as XML(to a XML document object) and pull your version number out via XQuery or XPath.
Of course that would probably bugger up your whole "versioning" scheme as you would be rendering the report twice. Perhaps add a parameter that indicates whether or not to increment your version number?
As a workaround, you could create a sub-report to do this. Instead of returning the version as an output variable, return it as a column in a resultset.
Hope this helps,
Bill