Is it possible to use SQL Azure Reporting Services with a SQL Azure database using Federation, with tables federated by tenant ID, and the requirement that all access to the database is done through a connection filtered by the federation key, i.e., filtered by tenant?
Merely connecting to a specific federation member database as suggested in this forum post wouldn't be enough, because one tenant must not be able to view another tenant's data. The connection must be filtered by SQL Azure Federations through the use of the "FILTERING=ON" condition.
Is there any way to have SQL Azure Reporting Services execute the necessary USE FEDERATION command to have the connection filtered by the federation key?
Or alternatively, to have Reporting Services access data in any other way (like an OData web service) that might be filtered?
The desired result is that each tenant can run a report and only see their own data.
SQL Azure Reporting Services is not federation aware (as of the current version), so your best choice is to write a service and have SARS use that service as the data source.
Related
I need to connect directly BIRT reporting tool to database cube, I am trying but with no result, could any one help with a working approach...
I am new to Azure and i need to know
Can We use SQL Server Reporting Service with Azure SQL Data Warehouse (as a data source)?
Big Appreciation for answering
Yes. Establish a connection to your Azure SQL Data Warehouse as if it were an Azure SQL DB.
If you write your own SQL queries for your report, ensure that it uses T-SQL that is supported on Azure SQL Data Warehouse.
Note: I have not verified whether the SSRS Report Builder tool generated T-SQL generates only SQL Data Warehouse T-SQL compatible statements.
I am setting up SQL BCDR for my project using SQL Server 2012 Availability group. I could successfully implement it for my database. But I have SSRS, which I want to include in the Availability group.
What is the best approach for this. Ideally, I would want my client to connect to the reporting server using the listener name or a common static name, so that during fail-over the client doesn't need to change anything.
Any good read in terms of configuring SSRS with AlwaysOn?
Thanks
This is a very common situation but certainly achievable with the built scalability feature in SQL Server 2012 (AlwaysOn Availability Groups). There are few limitations and things to consider when planning on using SSRS with AlwaysOn Availability Groups. Please refer to this link for further detail. http://msdn.microsoft.com/en-us/library/hh882437.aspx
In one of my application Iam using SQL SERVER 2008, I like to implement audit tables for few tables. One option I have to create triggers on the respective tables. Can anyone suggest me any other good, robust and secure option.
SQL Server 2008 has a new auditing feature: Auditing in SQL Server 2008.
There is also Change Data Capture
Triggers are the usual way to go. Another option could be to handle this in your stored procedures. Of course this assumes, that all data modification goes via stored procedure. Since you are on SQL Server 2008 and assuming you don't care about any lower version, check out the new auditing features here: http://msdn.microsoft.com/en-us/library/dd392015.aspx
You don't mentione which edition of SQL Server you are using as the Auditing features are only available in the Enterprise edition.
You should download a copy of the free eBook Developing Time-Oriented Database Applications in SQL by Richard T. Snodgrass from here: http://www.cs.arizona.edu/people/rts/tdbbook.pdf.
He talks about auditing and many other time related issues in databases.
Two interfaces of Reporting Engine are possible:
sql based for sql based user
non-sql Based interface for normal non-sql friendly users
Database is very large so how do I go about thinking about 2) option that is Non-sql based interface
How would it be ?
If you're using SQL Server 2005 or higher, you may want to consider the ReportBuilder supplied as part of Reporting Services.
You just need to build a 'business friendly' schema (known as a 'DataSource View') then auto-build a Report Model on top.
The users just connect to the Report Model using the Report Builder tool and they can create their own reports.
If you already have SQL Server, then the additional costs would be minimal.
You need an easy way to build SQL queries. Look at the wizards in all the desktop databases, but something that isn't paged might be more intuitive, e.g. http://ruleeditor.googlecode.com/svn/wiki/NSRuleEditor_Tiger.png (not affiliated)