Is there a way to use datasets from custom assemblies to populate SSRS datasets? - vb.net

I am tasked with converting some RDLC files to RDL that define their datasource with compiled VB.NET. Translating the code to TSQL is complicated for some of them, and it would be prudent to use the assemblies that are already developed if that is possible.

Probably best option would be to make a host for assemblies which exposes data as xml webservice, then in a report to use xml data source.

Usually there is no way to access the SSRS report dataset from Code Behind, you have to write queries for your Reports. But there is a kinda work-around . But it may have some performance issues..
Performance issues (Pros):
When you write your queries for the report, they are handled by ReportServer
and when you write stored procedures, they are handled by your Database server, in case your reporting server and database server are different
Performance issues (Cons):
When you don't want to go the above way and in the case you are developing the web application, you can surely make use of passing data to SSRS rdl from code behind through XML
and the Cons is that your data processing at the moment is not done by Database server but by the Server in which your application lies

Related

Advantage to using SSRS or Crystal reports when the output is simple and static?

I have an ASP.NET/C# web app in which the user needs to run reports with various criteria that will ALWAYS yield simple, 2-dimensional, tabular data. I'm tempted to use a sophisticated reporting engine like SSRS or Crystal Reports, but these seem like overkill, since there's really nothing to design (all outputs will be to CSV, or JSON for the browser to render in an HTML table).
In this scenario, am I eating too much complexity by trying to use SSRS or Crystal Reports? Should I instead just write custom classes to dynamically assemble SQL statements (based on user selections) that will be fired against the database?
Does SSRS or CR add anything that is of value (within the requirements constraints I've already described)...?
Its depend on your requirement if you want to minimal overhead on your web app then please go ahead and use your custom codes since you are not required any styling or extra functions.
Just get JSON objects and fill in HTML and go Head !!
I am working with ssrs So i will talk just about it:
ssrs is a very useful tool for building a Reports
all You need is sql server Stored Procedure to build your report
then deploy it to report server and use this report from your app
-now all you need in your app just one page for all reports and you path the URL
dynamically with report name
You need to know this :
-ssrs did not work correctly with all browser
for Exp :
-Print Btn just work with IE
so Mozila and Google you need to use java script to print Report
-some issue with criteria section :
there is no way to rename the 'select value' with drop down
so you need to use java scrip to handle it
also you find ( Null and chick box ) any customer did not know what null mean so
you need first to remove null keyword or to rename it to anther Keyword
also you need java script to do this
the most problem i have :
all reports in reports server so
when i go to a new client what i need
just Sql server no need to setup visual studio and ssrs tool
just to deploy all reports on client report server
its very bad ..
i solved this issue with tool i had make to deploy the all the report
and no need to setup VS just to deploy the report
i think that the most important problem i have
and all of it i found a work around to solve .. and it takes more time
finally :
use ssrs or CR its very easy to use and make report very fast no need to create a custom page for report and develop all its control just like print and export
report to PDF,excel or any type
but if you have a few report i think no need to use any reports tool

SQL Server Reporting Services VS rdlc and the ReportViewer

We are planning on creating reports to be run on the same computer that the database application is running on.
Can you tell me which of these is the best approach? (SQL Server Reporting Services or creating a rdlc ReportViewer report)
Also I tried to locate detailed rdlc ReportViewer report tutorials both in books and online and found none. It's probably because I'm looking in the wrong places.
We are also using VB.Net as the language.
All help will be appreciated.
In a nutshell, .rdlc is the client version. You cannot host these on the report server. These reports do not know how to fetch the data, you MUST get the data yourself and pass it to the report. For this reason, you cannot even preview the report while designing. ReportViewer.ProccessingMode = Local
The .rdl or server reports know how to fetch the data. You configure the datasource and upload them to the report server. Because of this, you can preview the reports while designing them. You can use the web/desktop ReportViewer control to run the reports from inside your app...like a proxy between your application and the report server.ReportViewer.ProccessingMode = Remote
I prefer rdl for any sql datasource, but rdlc is also good for cases where your datasource is very complex or can only be built through the application code. I think there might be ways to configure an object datasource for rdl but I haven't looked into that yet.

SQL: programmatically copy stored procedures from one db to another

I'm looking for a way to copy stored procedures from one sql database to another on the same instance. It needs to be automatic, preferably through code (t-sql or anything), so using the generate scripts trick is not viable (plus I don't want to maintain that many scripts, and people forget to run them).
I've searched a bit on this and have not found a workable solution. Someone suggested a clever trick with generating all the stored procedure text into a sql field and then converting that and executing it on the destination db but unfortunately that had issues.
Has anyone got any other ideas on how this can be done, if it's at all possible?
If I can't do it programmatically, would there be a quick solution using ssis?
Thanks.
Edit: Using mixture of sql 2005 and 2008 versions.
You can do it programatically in .NET using the SMO framework.
Free/easy implementation could be done via PowerShell.
I have a script that does just this - it generates the scripts for SQL objects, including Stored Procs, and executes the creation scripts on the target server.
It's a handy workaround when security concerns don't allow linked servers but you need to keep certain resources in sync across multiple servers.
If all you care about are the procs, it should be fairly straightforward to check sys.sql_modules on your source and target DBs and execute any that don't exist in the target via the definition field in that view.

Decrypting data for use with SQL Reporting Services 2008

I have recently started to look at sql reporting services.
I have data stored in a database which has been encrypted with an AES cypher before being stored away.
I've had a look at building some reports using Microsoft Report Builder 2.0 and it seems quite nice and simple for knocking together some simple reports.
My question is: Can I decrypt this data before displaying it on a report? Is there anyway to run code with these reports?
Use a RDLC (C is for Client), and then look at the Microsoft.Reporting.WebForms and Microsoft.Reporting.WinForms namespaces.
This allows you to use code to generate your data, for example get your data from SQL Server then decrypt it as required before presenting it to the ReportViewer control.

VS2008 Save Query Results to file/xml

When I use the query designers in VS2008, how do I save the results to a file?
The output window is truncating the XML datatype - even if it didn't truncate, it still requires cut and paste to save the results to a file.
I don't think the built-in VS2008 query designer is intended or designed for that task. It works well for designing and tweaking queries - but if you need to really extract the data, I would recommend going to the MS SQL Server Management Studio (if you're using SQL Server) or any other dedicated front-end for your database system.