I have a report that consists of two graphs, with two separate datasets. They are overlapped and displayed or hidden based on a parameter on the report.
When tested in Visual Studio the report displays and runs fine (although a warning about overlapping report items is thrown), but when deployed to to our production setting, the report fails and throws an error that the Query failed for the Dataset that is hidden.
For example, datasets are WOs and WOsByAsset. When WOs is selected for display the error is Query Execution Failed for dataset WOsByAsset. When WOsByAsset is selected for display the error is Query Execution Failed for dataset WOs.
I have confirmed that both datasets work in SSMS, no actual errors are presented.
Could the fact that the graphs are overlapping cause this issue? The pattern of the errors appears to indicate that but I'd like any confirmation, or better yet, explanation that anyone may be able to give.
Thanks all for the suggestions.
Problem was of my own making. I had not taken into account that the report runs for each dataset even when the datasets related table was hidden. The report used a multivalue parameter, and by default passed all possible choices within the parameter into the report.
This was causing that dataset to fail, but when I tested the query in ssms I was only passing a single value for which the query ran just fine.
All good here.
Related
I am pretty experienced in SSRS, I have been doing it for quite some time so I know when I see the error:
"An error has occurred during report processing. (rsProcessingAborted)
An attempt was made to set a data set parameter '#SiteId' that is not defined in this data set. (rsUnknownDataSetParameter)"
I know what causes this error and can fix it. However, this error randomly happens every so often. What I end up doing is simply rebuilding the project and redeploying it and all is well for a few days, then suddenly again this same error will pop up again.
I know there is no issue with the parameter as I have a #SiteId parameter as shown:
So when I get an email from a user that "The Report Is Down" I just go to my report and rebuild and republish and the error vanishes without ANY other changes. A few days later when they want to run the report again this same error happens. What is causing this issue to come back over and over. We are running SQL Server 2016 with SSRS. It happens to ANY one of my reports on the report server. Its not a specific project it randomly happens on any project.
EDIT
What I did notice does happen is when a user reports this issue I go to the "Manage" of a report on the report server url. This area is where you find the properties, data sources, and parameters. When I click parameters I see this error:
So obviously something is destroying the parameters - that is where I am confused what is causing that. This is probably why I am getting the error message. So to reiterate a report is published works...suddenly the parameters go missing. User reports "the report no longer works" I rebuild and redeploy the report...it then works again for a day or so maybe more than a day I never investigated how long it takes for it to break again (as these are not urgent reports). Days later user says report is dead again...if I go to the report server using the report server url and click "Manage" and then click "Parameters" for some reason the parameters have disappeared...causing me to yet again redeploy. This happens over and over and over. It never ends...
The short of it is you cannot have the same shared dataset name across different SSRS Projects that are on the same SSRS server.
So within our SSRS "repository" we have several different SSRS projects. Both projects are very specific to certain functionality. What I noticed is everytime I deployed one of these SSRS projects the reports on the other project would stop working.
When the email would come from the user stating Application A's reports werent working I'd go to Application A's SSRS project and redeploy it and it would fix the issue. Days later a different user said Application B's reports weren't working so I would redeploy application B's. Not knowing that when I deployed A's reports B's would break, and vice versa deploying B's broke A's.
Come to find out....both projects had a shared dataset with the SAME NAME (dsEmployees). Same name however these datasets pointed to different sprocs with different parameters. Well when you deploy and look at the back end db the Catalog table only has one entry for dsEmployees. Everytime I redeployed this would overwrite with the other dataset since the names were the same.
Lesson learned across different SSRS projects be careful with the shared dataset name, they must be different. I was able to spot the difference by running the following query:
SELECT
c.Name,
c2.*,
c2.Parameter
FROM
DataSets d
INNER JOIN
[Catalog] c
ON
c.ItemID = d.ItemID
INNER JOIN
[Catalog] c2
ON
c2.ItemID = d.LinkID
WHERE
--one specific report for now
d.ItemID='C3008EF4-E544-48F3-92C1-2222C6148B13'
When the report was stated not to work. Then I would redeploy the report and rerun that sql statement I wrote and dumped the rows to an excel sheet to compare. One of those columns is Parameters and I noticed the parameters were slightly different. Immediately I was onto something and this ended up being it. Thanks to comment posted it helped me relook at this! This has bugged me for years!
I took over report creation/maintenance at a new job. We are using SQL Server 2012 and SSRS 2012. When I try to edit one of the older reports using Report Builder I find I can't even add a comment to some of the code in a dataset without breaking the report. This particular report has 14 parameters and all I have to do is try to add a comment line (never mind change the code) to a dataset and click OK to close the dataset edit it presents this DEFINE QUERY PARAMETERS prompt to verify the parameters. If you click OK then all the fields disappear from under the dataset in the Report Data window and the report doesn't work.
Running the report itself without trying to apply any edits still works fine, it's the editing that breaks it. I can edit other previous reports, it's just this particular report that's showing this behavior.
Finally figured it out after all this time. The SQL for this dataset has at least a dozen IF-THEN statements spread throughout the code, that keep checking for a certain input parameter that was selected. I finally simplified the previous report writer's code into one big IF-THEN-ELSE statement and now the dataset can be edited in Report Builder and Visual Studio with no problem. I'm guessing something changed in Microsoft's SSRS parsing routine between when this report was written in 2018 (where it had no problem with all those IF-THEN statements) and 2020, when the parsing failed but with no helpful error message.
I've returned to our reports collection after a couple of years away, and added a new report which has a simple tablix containing a few columns, but many rows from the dataset.
The problem is, the report (in Preview in VS, and when run on the Report Server) only shows some of the rows returned by the dataset, and doesn't enable the page navigation icons in order to scroll through the data to access the rest.
Where do I find the settings which control these things, please?
UPDATE:
Looking at some pre-existing reports, it seem that these exhibit the same problem - it would appear that SSRS can only display about 5,000 rows regardless of how many the dataset contains.
There is a 'hidden' setting in the XML code (not available via the UI AFAIK) called InteractiveHeight. Removing this line resulted in the paging starting to work
I have a SSRS Report with six sub-reports. The sub-reports are using the same shared data source which the main report is using.
When I deploy the report and execute, the sub-report place holder shows error: Report cannot be shown.
I thought it could be due to shared data source. Therefore, I created separate shared data source for each sub-report. This works. The report starts showing all the results.
Please let me know what is this issue. Even though it works, I don't want to create separate shared data source for each sub report.
This is a known defect in SSRS 2008. I'm not sure if it has been patched yet, but it has been fixed in SSRS 2012.
As you have found, the workaround is to use separate datasets.
https://connect.microsoft.com/SQLServer/feedback/details/648560/subreport-with-shared-dataset-throws-error
I have an issue with a report causing an "Object reference not set to an instance of an object" exception when run through my web application. This is, so far, only happening on one QA machine.
I can:
Run the report locally on my development machine (latest code, same database)
Run the report through the Reporting Services Web Interface on the QA machine
Run the report on the QA machine through my web app if I select a format other than PDF/TIFF (e.g. Excel, CSV, HTML, XML all report successfully)
The Reporting Services log on the QA machine looks like this when I get the exception.
I did not find the log helpful so I started whittling the report down to a minimum to find the issue.
What I found confuses me.
Given the following RDL; I can change the height of Tablix list1 from 3.09444in to 1in, deploy the report to the QA server and the report will run successfully.
How in the world could shortening the height of Tablix list1 prevent the exception?
UPDATE
It's not moving height of the tablix to 1in. It's getting rid of the long decimal on the height. I changed (3.09444in to 3.1in) and the report ran successfully. FTR, I did not choose the height 3.09444in...rs chose that for me while I designed the report.
Fixed by changing the long decimal on the height of a Tablix from 3.09444in to 3.1in.
I did not choose the height 3.09444in.
The Reporting Services designer chose that for me while I designed the report.
I've experienced this problem a few times. It typically happens to me when I have a hidden textbox executing some Code.xxx routine and that textbox is located under a table, and the table has some kind of group page break.
It seems that with each page break, the fields hidden under the table are refreshed and sometimes they get a object reference error.
Here's the weird thing - I can typically fix the problem simply by moving all the hidden fields to a location such that their upper left corner is above the table's upper left corner, or to the left of it. It's like the position of the field somehow has some influence on what is refreshed and what is not.
I do not claim to know why it works, it just does.