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.
Related
I am working on migrating an application from one server to the other. According to the connection string of this application, it is touching different databases. Meaning a view query in DB1 will touch a table in DB2. So while migrating this application, I constant get to see chain of 'Database unavailable' errors and every time I see such error, I have to migrate that specific database.
I am wondering, since we have ER diagrams to know about relationships between tables in a database, is there any way in SQL server to know the relationships/linkages between different DATABASES in a server? Are there any tool that does this?
Depending on number of databases you have, here would be a somehow quick way you can find that out (number of required search = number of available databases in the server):
Use 'SQL Search' application of Red-get
(https://www.red-gate.com/dynamic/products/sql-development/sql-search/download)
and search for the other database names one after another by selecting
your database of interest. Select all objects.
If you have metadata oriented design (a Stored Procedure looping through the names of different other Stored Procedures / Functions from different databases which are stored in a table as metadata and executing them with a wrapper Stored Procesure), then you will have make use of SQL Locator software (http://www.sqllocator.com/Downloads.html) to search for database names in SQL Table values.
Both of the above software are free.
You need to have SSMS (SQL Server Management Studio) installed to be able to use this application. After installation, ‘SQL Search’ will be directly available in your SSMS as an add-on.
SQL Locator can be directly used by providing the SQL Server name and your SQL Server credential.
Note:- The above steps will help you find out the referenced databases from a certain database within the same SQL Server. If you need to find out databases from Linked Server (I do not believe your question is asking that anyways), then you will have to smartly utilize the same above tools to find the external server reference by searching the external server name.
I work in my companies small IT department. I have been creating automation via VBA in Excel to pull data from SQL and put it into Excel, then dynamically format and summarize the data. The issue I am running into is the IT department does not want to give anyone outside the IT department SQL Read-Only Access. They view SQL as a privilege not a right...even if it is only Read-Only. They claim security reasons.
Just to be clear, we are NOT installing SQL on these peoples' computers nor do they have the technical understanding on how to write queries. Also, they can already view all the information on the front-end website.
I currently have to specify which database and which tables they can have access to and it takes about 1-2 weeks to give them access (they drag their feet doing the requests).
I am not trying to vent, I am actually wondering do they have a legit concern about security and is this actually a best practice on their part?
The worst thing that could happen is a user knows just enough to connect MS Access to the database, write some poor queries, and grind everything to a halt. You should always have non-IT users access data in a safe, structured way. Especially if this database is a transactional one, and not a reporting database.
Sure, they can access all the data per business process. So then, create a nice, safe query to read all the data and dump it to Excel - if that's what the users want.
Otherwise, IT-created queries - preferably in Stored Procedures - should be reading the data and presenting it to the users.
So it's not a security issue per se. It's more an issue of "we don't want non-IT users getting crafty and bringing down the database with poorly written queries."
I believe the connection properties to the SQL server is embedded in your VBA code, as long as the code is not visible to the user then there is no way they can query the SQL server directly.
Sounds like you need an SQL read only service account which you can use for Query connections. Create an Excel data connection that has the security details to connect to SQL, then your VBA hooks into that data connection.
So, it looks like I'm gonna have to replicate a couple of reference tables from my SS2k5 db on SP2k7 in order to do dropdown boxes on my document library. Small tables, maybe a hundred entries, and not often updated. Ths SP Server is not the SS server.
I know how to build triggers, but how do I reference the SP table to update it from the SS trigger, and what are the authentication issues?
Anybody do this before?
I know there is a thing called Business Catalog Data or something like that, but I don't have full privs on this SP site, so I'm likely not to be able to get to that, and I've never used it before, hence the trigger idea.
Does it really need to be real time via a trigger? Or can it be delayed and processed via an ETL job? If the latter is acceptable, I recommend taking a look at Extracting and Loading SharePoint Data in SQL Server Integration Services. I have used this adapter on past projects to transfer data between SQL Server and SharePoint.
P.S. I would not recommend writing directly to the SharePoint content database. Making changes directly to a content database is not supported and is not considered a best practice.
We have a peculiar challenge with overly-strict use restrictions, and I'm trying to find a way to accomplish it.
We have data in two locations, on different platforms. We are extracting data from application tables, and we aren't allowed to create our own views/procs/etc.
Is there a way to run a query into a remote Oracle DB from within an SQL Server query?
To further complicate issues, we have to make it run through a Crystal Reports database command.
We have ODBC connections defined at the BOXI platform (using Oracle ODBC for the Oracle connection).
I am hoping to use the SQL WITH clause to build in-memory views (for lack of a better term) to:
Initially extract some circuit IDs from the local SQL Server system,
Extract ticket numbers based on those circuit IDs, from the remote Oracle system,
Extract the core of our data from the SQL Server system, joined with the ticket data and return that to Crystal as a result dataset.
If we had our own space, this would be trivial.
BOXI doesn't let us do multiple-server universes.
You would need to some way to write and store connection strings, but it doesn't sound like you're able to do this.
If you can't make ANY changes to either source system, you might try creating an MS Access DB and using linked tables to bring in all the information you need and have your Crystal Report run from that. You would then only need to make sure that the machine you're running this on has the ODBC drivers to be able to connect, which are simple enough to configure.
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.