I'm using SQL Report Builder and I would like to call the stored procedures that were already built. SSRS allows me to do this but since the company's requirement is to build a report model to allow users to do their ad-hoc reports, I need to find a way to include these stored procs written to populate some of the tables.
Can anyone please help me with this?
Thanks.
When you use SSRS to create a Report Model project, you create a data source and then a Data Source view (DSV) which is a restricted list of tables & views available for the report model.
The idea is to create a limited set of views for the Report Model so that report creation is simple and unambiguous for end users. It's not recommended if end users are not going to be the ones creating reports. In practice, Report Builder is not powerful enough for power users, and other users are not going to get a lot of value from it that they couldn't already get from connecting Excel to the datasource and creating pivot tables.
Unfortunately with Report Builder you are limited to tables & views.
This immediately means that complex reports should not use Report Builder. Anything fancy is not going to be easy to reproduce in a view because they don't take parameters.
If it definitely required, then you need to somehow create a view from those existing Stored procs.
One way is to convert them to use table valued functions (TVF's ) . That is not an easy process because you still then need to incorporate the TVF into a view and it still won't be able to take parameters.
Teo Lachev's book 'Applied Microsoft SQL Server 2008 Reporting Services' lists another workaround on page 312. You can use OPENROWSET to create a named query. This relies on you having already enabled SQL Server for ad hoc distributed queries (server option).
The example he gives:
SELECT a.* FROM OPENROWSET('SQLNCLI', 'Trusted_Connection=yes',
'[AdventureWorks].[dbo].uspGetManagerEmployees 16') AS a
That actually seems like the least amount of work for you.
The best option is to just do the reports in SSRS and reference the stored proc as is.
Related
I have a SSRS Sales report that will be run many times a day by users, but with different parameters selected for the branch and product types.
The SQL query uses some large tables and is quite complex, therefore, running it many times is going to have a performance cost.
I assumed the best solution would be to create a dataset for the report with all permutations, ran once overnight and then apply filters when the users run the report.
I tried creating a snapshot in SSRS which doesn’t consider the parameters and therefore has all the required data, then filtering the Tablix using the parameters that the users selected. The snapshot works fine but it appears to be refreshed when the report is run with different parameters.
My next solution would be to create a table for the dataset which the report would then point to. I could recreate the table every night using a stored procedure. With a couple of small indexes the report would be lightning fast.
This solution would seem to work really well but my knowledge of SQL is limited, and I can’t help thinking this is not the right solution.
Is this suitable? Are there better ways? Can anybody confirm either way?
SSRS datasets have caching capabilities. I think you'll find this more useful instead of having to create extra db tables and such.
Please see here https://learn.microsoft.com/en-us/sql/reporting-services/report-server/cache-shared-datasets-ssrs?view=sql-server-ver15
If the rate of change of the data is low enough, and SSRS Caching doesn't suit your needs, then you could manually cache the record set from the report query (without the filtering) into its own table, then you can modify the report to query from that table.
Oracle and most Data Warehouse implementations have a formal mechanism specifically for this called Materialized Views, no such luck in SQL server though you can easily implement the same pattern yourself.
There are 2 significant drawbacks to this:
The data in the new table is a snapshot at the point in time that it was loaded, so this technique is better suited to slow moving datasets or reports where it is not critical that the data is 100% accurate.
You will need to manage the lifecycle of the data in this table, ideally you should setup a Job or Scheduled Task to automate this refresh but you could trigger a refresh as part of the logic in your report (not recommended, but possible).
Though it is possible, you would NOT consider using a TRIGGER to update the data as you have already indicated the query takes some time to execute, this could have a major impact on the rest of your LOB application
If you do go down this path you should write the refresh logic into a stored procedure so that it can be executed when needed and from other internal and external automation mechanisms.
You should also add a column that records the date and time of when the dataset was executed, then replace any references in your report that display the date and time the report was printed, with the time the data was prepared.
It is also worth pointing out that often performance issues with expensive queries in SSRS reports can be overcome if you can reducing the functions and value formatting that is in the SQL query itself and move that logic into the report definition. This goes for filtering operations too, you can easily add additional computed columns in the dataset definition or in the design surface and you can implement filtering directly in the tablix too, there is no requirement that every record from the SQL query be displayed in the report at all, just as we do not need to show every column.
Sometimes some well crafted indexes can help too, for complicated reports we can often find a balance between what the SQL engine can do efficiently and what the RDL can do for us.
Disclaimer: This is hypothetical advice, you should evaluate each report on a case by case basis.
I am trying to get everything
find all the tables, views, stored procedures, scalar functions, table functions, schema using sql query of a specific database
I actually wanted to create a autocomplete option but as of now my first step is to get everything in a list but not sure how i will get all of the above of a specific database
This is a bit long for a comment.
You need to look into the system tables. Personally, I prefer the standard INFORMATION_SCHEMA views, but the information you want is spread out.
In SQL Server, you can use sys.objects, paying attention to the object type. The place to start learning about it is in the documentation.
I was wondering if anyone can help. I have started a new job for a firm where they are looking to create BI reports for clients. The clients have the server on their site. We have access to only query the data, but not allowed to create tables, stored procedure etc.However we are allowed to create temporary tables.
I am looking to create an SSRS report for the client but at the same time want hide the SQL from them to prevent them knowing how the reports are built.
Is there a way to create a self service bespoken report which I can deploy for them but keep the SQL hidden from them, despite them having the server on their site and them having admin access to the sql server box and SSRS reporting server?
Any advice on best handling this tough situation will be greatly appreciated!
For the purposes of this answer I am ignoring any ethical issue with this question.
Short Answer:
There is no way of doing this with SSRS and your restrictions on the client database.
Long Answer:
SSRS reports are stored as a .rdl file on your clients reporting server. This is basically easily readable XML which will allow anyone with an interest to view the report definition.
If the report definition also contains the dataset SQL (SELECT secret_sql FROM table) then the client would have:
The definition of the report, in order to be able to modify it.
The definition of the dataset, in order to modify it or apply it to another report they design.
Your only chance would have been to obfuscate your SQL on the actual SQL Server (WITH ENCRYPTION) however
You state you're not allowed to do it
The client may be able to either decrypt or using SQL Profiler detect the SQL you are running and therefore capture it for reuse.
I am using report builder 3.0 (very similar to SQL server reporting services) to create reports for users on an application using SQL server 2012 database.
To set the scene, we have a database with over 1200 tables. We actually only need about 100 of these for reporting purposes. But it is very common that we need to combine fields from multiple tables together to get a common resource of data that my colleagues and I need for our reports.
Eg if I want a view of a customer, I would want to bring in information about the customer from the customer_table, information about his phone details from the Phone table, information about his account(s) from the accounts table and so on. Then I might need another view of the accounts - account type, various balance amounts, opening date, status etc.
What I would love to do is create a "customer view" where we combine all these fields into a single combined virtual table. Then we have an "Accounts view". It would be easier to use, easier to manage etc. Then we use this for all our reports going forwards. And when we need to, we can combine the customer and accounts view to use on a report plus actual tables into one combo-dataset to use on a report.
I am unsure about the right way to do this.
I see I can create a data source. This doesn't seem right as this appears to be what one might do if working off 2 or more databases. We are using just 1 database.
Then there are report models. It seems these are being deprecated and phased out so this doesn't seem a good option.
Finally I see we can create shared datasets. However, this option (as far as I can tell) won't allow me to combine this with another dataset. So using the example above, I won't be able to combine the customer view and the account view with this approach to use for a report to display details about the customer and his/her accounts.
Would appreciate guidance on the best way to achieve what I am trying to do...
Thanks
I can only speak from personal experience, but using the the data source approach has been good for our purposes. We have a single database with 50+ tables in it. This is linked to as a shared data source in the project so is available to all 50+ reports.
We then use Stored Procedures to make the information in the databases available to the reports, each report has it's own Stored Procedure that joins as many tables as required to provide the data for the report. The advantage of using Stored Procedures also allows you to only return rows you are interested in, rather than entire tables.
I'm not certain if this is the kind of answer that you were after, but describes how we solve a similar (smaller) issue.
I'm trying to narrow down the results returned from a server generated SSRS report, but the customer is requesting too many fields to do be able to do it easily with parameters into a predefined SQL statement.
Is it possible to pass a statement into the reporting server from .NET that the server will execute as its datasource, instead of the preconfigured one? Either the complete statement or the WHERE clause would be fine.
If not, is it possible to eval a parameter sent into a stored procedure? I'm aware of the security implications.
Architecturally speaking, if the customer is requesting reports with infeasible amounts of parameters they might want to consider creating an Analysis Services model instead and using Excel or another tool to slice and dice the data to their hearts content.
I can't speak to the .NET option, but you can definitely use a stored procedure in a report data set, but I'm not sure how that would help you as it would still require parameters to be passed to it.
We decided to route a parameter into a stored procedure, which executes a sql query using the parameter. The other parameters use the Prompt as a friendlyname and the Name as the column name, and the program constructs a where clause from this information and passes it into the query parameter of the report. It's not a perfect solution, but we've closed all holes for injection we could and it works. Sometimes you've got to be happy with that.