I have created an SSRS Report which loads all the columns as expected in my local preview when viewed in Visual Studio. But after deploying to Report Server, it shows 0 in columns that have numeric data. These columns are of Varchar, Big Int data types. Columns that have DateTime, string type show correct data.
I tried below without any success.
Redeploying the report multiple times.
Removing and re-adding columns.
Removing .data files every time I change something.
My SSRS Version is 15.0.19049.0. Can someone please help me understand what might be causing this weird issue and how to resolve it?
Related
I am looking for some direction on how to solve this SSRS problem. Basically, I am migrating a 2012 sql server to a 2016 server. I am on the last leg which was to ensure the SSRS reports being sent out match the old prod reports.
Two of the three reports being sent out are inaccurate. One report shows up completely missing all numerical data, aside from the layout of the report. The second report has all the data in the correct locations, however it is doubling the data in one of its 3 columns. They are connected to an internal data source.
I transferred these reports by downloading (rdl) them from the Old Prod SSRS and simply uploading them to the new Prod SSRS. I have tried tinkering with the report builder/visual studio but I'm not sure what to look for.
Can you please point me in the right direction of where to look or if there is an easier way to migrate said reports?
Something really strange is happening with SSRS. I have a report which is powered by a stored proc which uses a lot of TSQL and CTE's to set variables ect... I know that there's no problem with the procedure as it runs in SQL and also runs within Visual Studio and returns a full data set. The issue I'm having is on deployment, I can't seem to get the report to return data when running it from the reporting server. The headers of the table and parameter are displayed but just no data.
I've tried the following:
- Deleting the .DATA file
- Clearing cache
- Checking for data source errors
- Checked the report server error log
- Rebuilt RDL and created a different report with the code
I'm clueless on this one, it's something I've never seen before.
Please help.
Much appreciated,
Thank you
Ri
I'm using Visual Studio Pro 2013 and want to use the Fuzzy Lookup task but there seems to be a bug that prevents the component from connecting to the reference tables.
A reference file and table is specified in the Connection tab which all seems fine but the Columns tab is also needed to create the reference links between different fields of the data however there is nothing there:
The error messages are as follows:
I've read elsewhere this was a known bug on older versions of SSIS from about 2005 - anyone know what the problem is here and how I can fix this?
I should add that the connection manager and the table seem fine as they have been used many times elsewhere in the project. I've tried recreating the data flow in a new document and even restarting my PC but this simply won't work. I should add that I've not used the Fuzzy Lookup before but have looked at several references and know that the column tab should be populated with data and not be an issue.
Many Thanks,
Kw
Not a bug, it's how the product works. From the manual, it specifies the reference table must be a table in sql server. A table in Access, therefore, is unsuitable for use in the fuzzy lookup component.
The transformation needs access to a reference data source that contains the values that are used to clean and extend the input data. The reference data source must be a table in a SQL Server database
I'm using Visual studio 2013 with update 3 and a collegue of mine with update 4 installed each. We are using the data dools for sql server 2014.
I've created a few DTS packages which my collegue updated so far it worked without problems.
But all of a sudden I get "value does not fall within the expected range" warning from the datasource and can't edit columns there,.. . I needed to recreate the datasource for the message to disappear again.
My question here is can it be that the appearance of additional columns in the table which the datasource accesses was the cause of this problem? (I've seen out of sync warnings for datadestinations whenever a destination table got new columns or lost columns, but this is the first time something changed for a source table).
Or can that problem have a completely different cause?
It has been a long while since I've worked on an SSIS project, but I do recall seeing this error as well.
My experience was that it was caused to the metadata of the input being out of date in a certain way, and what you describe as your suspicion fits with this.
The solution I found to avoid this was to be very specific on all my input components, selecting the exact columns I wanted rather than selecting all. I think in the end I actually changed them all to use hand written SQL queries rather than the GUI column selector.
Also I don't remember if this was the same error but a similar one: sometimes after a schema changing when trying to open a component the GUI would throw an error and not open but when I tried again it would have resolved the error.
Sorry I couldn't be more definitive in my answer but hopefully this information helps point you in the right direction.
I used a simple method and it is working fine. In the OLE DB Source Editor while I retained the same connection manager, changed Data access mode (from Table/View) to SQL command and used SQL command to select the required columns. Error message no longer appeared and I could see the column values....
I can run all my reports from report studio just fine. So its not a question of query or data or even report specs.
When i call them from URL i am getting no data in the report. There obviously should be data.
We had just upgraded from 8.2 to 8.3 and it is not all the reports... only a select few.
This is serious problem since our users can no longer run these reports.
please help.
-k
This was worked around by recreating the reports from scratch in 8.3 by copying over all the contents using the clipboard and saving it over the old one. There must be something wrong with our reports and the cognos upgrade engine.
This fixes 90% of our reports. we still have some that do not behave correctly.