We have an ASP .NET MVC web application that links to some SQL Server Reporting Services reports. Our web application uses one database for the morning (let's call this the "AM database") and a different database for the afternoon/night ("PM database").
We have a SQL Server Agent job set up that switches the connection string for the web application from the AM database to the PM database (or vice-versa) on a schedule. It works by copying/replacing the MVC application's Web.config file with the appropriate AM/PM version. This works as intended.
However, the reports will remain pointed to whichever database they were using previously, unless the data source is manually changed through SSRS. These reports need to be updated to point to the same database as the MVC web app.
How can I automate this process (preferably through SQL Server Agent)? We need the reports to change their database connection on a regular interval.
This works for embedded connections I am not sure about shared data source references. Just add two parameters to your report for database name and database server name. You could also use codes or mask the names if you prefer not so send this info over the wire.
In your embedded data set add the following as your connectionstring
expression:="Data Source="+Parameters!DatabaseServerName.Value+";Initial Catalog="&Parameters!DatabaseName.Value
Next, add a defined user for your credentials then all you need to do is pass in the two params for each report from your application.
NOTE: You need to add your defaults when designing to a server that is accessible.
Related
For many years we've had a reporting database that we have written our SSRS reports out of, which includes some linked servers. The linked servers are set up on the SQL instance where reporting services lives, as well as the main databases we use to report out of. We've decide to split off reporting service from the main server, and give it its own house.
I've setup SQL 2014 along with reporting services, and published my reports over there instead. All of the 'non-linked' reports work fine. However all the reports that reference a linked server (that used to work on the main server) now fail with the following error in the log file:
Access to the remote server is denied because the current security context is not trusted.
I thought maybe I needed to set up the linked servers on the new RS SQL server to get this to work. I had assumed that it would pass the entire query (including the linked part) over to the data source specified and my primary server would run it and return the data. Nevertheless, I set up the exact same linked servers on the new reporting services box... but still receive the same error.
All these reports worked just fine on the original server, however they all seem to be having issues on the new server no matter what linked server they are connecting to.
I am at a loss, and would love any ideas you guys may have.
Server A:
Main Data Source. This server contains the majority of our data and also housed our Reporting Services. This server has links to several other SQL servers that I was able to openquery to, and join the data to our main data source. We have many published reports that utilize the linked servers and have historically provided no issues.
Server B:
New SSRS box. This new server was set up in an attempt to off-load all of our reporting needs to another box thereby freeing up any resources required to run reports and SSIS packages. I took all of our existing reports and published them to the new server as-is. Initially I didn't think I would need to recreate the linked servers on this box, since those requests would be going to my main data source (Server A). I've tried both with, and without the linked servers existing on Server B, but get the same results. When the linked servers DID exist on Server B, I was able to query them directly with no errors. The services on Server B are running under the same credentials as those on Server A.
Well, I did some more digging and found my resolution. So the data sources have always been using the end users credentials to run the reports. On the old server, the linked servers use a hard coded SQL account to make the connection. This works fine so long as it is all on one server. However, when running from a secondary server it appears that this scenario will not work. Instead, I found that if I make the data source use the 'same' hard coded SQL account and the linked server to make the connection to Server A, the linked servers work fine.
I have a SQL server reporting service production environment. I need to duplicate this environment on a totally different machine including the source data, let's call it Dev environment. I have backed up and restored both the source database (sourceDataDB) and the report databases (ReportServer and ReportServerTempDB) to this new machine. Re-configured the new reporting service to point to the new report database. Everything works except when I run a report, the report pull out data from the original source database instance instead of the newly created instance. Of course, I can manually modify the data source information from the Report Manager on the new report server. The challenge is every time the ReportServer and ReportServerTempDB got refreshed from the production database, the modified data source got replaced with the one from production environment.
I wonder if there is a way to automate the process of modifying data source information after each database refresh, either from the database end or from the report manager. I only have one data source that is shared with all the reports. This is a SQL Server 2008 R2
Thanks in advance.
Is it possible to find back which application made changes to a database (e.g. update a record)?
I'm using SQL Server 2012.
You might have to ask your developers to start including Application Name in their connection string in web.config files of their application.
Data Source=myServer;Initial Catalog=myDB;User Id=myUsername; Password=myPassword; Application Name=MyApplicationName;
Then you'll be able to use APP_NAME function to track the application connecting to the session or can also be used in the store procs.
Also, you can use Application Name to filter queries in your Sql Profiler, otherwise in absence of Application Name, all application gets generic app name, .NET sqlClient Data Provider
TThanks, for reading, I'll try to explain my issue in a detailed format as the question I'm asking is a bit high-level for my experience-level.
I'm using VS2005 and SQL Server 2005 with Reporting Services. All of my reports are built in VS2005. The reports are deployed to folders named "Amort" or :Amort_Test" on the Report server depending on the configuration I choose when I deply (Production delpoys to "Amort", Test deploys to "Amort_Test").
In Reporting Services Report manager, I have a data source setup call AMORT (and that is the datasource in my VS2005 reports). The datasource is of type Microsfot SQL Server and the connection string is "Data Source=uslibsql310;Initial Catalog=AMORT_P".
What I'd like to do is have the ability for the reports in the "Amort" folder point to a database called AMORT_P on my server (uslibsql310) while the reports in the folder "Amort_Test" point to the database called AMORT_T on the same server (uslibsql310). Obviously my current configuration, where reports in both folders point to the same datasource, says that reports point to the AMORT datasource which currently points to AMORT_P.
My initial thought was that I could create a new datasources, call it AMORT_Test and have its connection string be ""Data Source=uslibsql310;Initial Catalog=AMORT_P". However, every time I'd deploy my reports, I'd have to change the datasource in VS2005 to read AMORT_Test instead of AMort and then deply, which would be abit of a hassle.
Can anyone think of a more user-friendly solution to this? I'm one who normally finds the quickest solution and goes with it, but in this case I think there must be a way to set this up so that the reports in one folder know to pick one DB and the reports in another folder know to pick a different DB, but my current setup doesn't allow that. I'm not sure where to start in trying to figure this out as I'm a bit of an RS novice.
You're almost there, I think. If I understood correctly, here's your current setup:
One shared datasource
Reports all use that shared datasource for datasets
Two configurations: test and production, each with its own target folder
What you can do now is set OverwriteDataSources to False. Manual labor is required to set the connection string for deployed reports only:
For initial deployment of reports
When you want/choose to change the connection for deployed reports
This manual labor can be either:
Changing the connection string, temporarily enable OverwriteDataSources, and re-deploy
Going to the report manager web frontend to change the connection string
However, your default setup would be to deploy reports to both configurations, without having to worry about connecting test reports to production databases and vice versa.
I am new to SSRS and have deployed several reports. When I force windows authentication, everything works fine, but when I do this:
I am getting this error:
An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for dataset 'DataSet1'.
(rsErrorExecutingCommand) Login failed for user 'DWH_Reporting_User'.
I've configured the DWH_Reporting_User like this:
here are the details on DWH_Reporting_User for the ReportServer database:
here is the security on the server:
when i try to set security for that specific folder:
i am getting this error msg:
is there something obviously wrong with the way I've configured things?
The answer to this question was a series of comments. I went ahead and put it in the chat as well as an answer.
Go to the security of the server not the database and map the user to that database.
Can you recycle the application pool on the server where reporting services is running? Or reboot the IIS server if possible.
Another thing that comes to mind, when you launch this report it goes into the report server "Portal". Does this user have access to the actual report to view it? Click the details section of this "Portal" and assign this user as a content manager role.
DWH_REPORTING_USER is this an admin account on your domain?
Local admin on the server, so did you grant \COMPUTER_NAME\DWH_Reporting_User rights as a content manager in the roles section? Why dont you use a domain admin account?
So how do you access the actual report - that is your issue.
Do me a favor aprem, write up a stored procedure or sql query in the first tab of reporting services and run it using that user. Meaning in the shared data source it should be using this user DWH_Reporting_user. Test the connection then write a small sql statement to retrieve some data. Run the SQL script from within RS do you see any data?
#Aprem look at the three tabs at the top of rs, its the first tab to define datasets, this is where you can create an SQL query (and run it using the red exclamation mark). – JonH 20 mins ago
i defined a new dataset as "select top 1000 * from mytable", i rebuilt the project, deployed it, and now what do id o? – Артём Царионов 16 mins ago
In the "Shared Datasets" you have a dataset right? Double click on it and go to "Query Designer" it is a button on this form. Click on it and "Execute" the query (red exclamation mark). You dont need to deploy it right now, just do it on a test machine.ago
You specify the user in the datasource section "Shared Data Sources", that account is the account being used to "pull" the data. You really need to experiement with RS some more or read some material on it. This is as basic as it gets.
*Ok aprem do you understand your issue now, the user you are using to get the data has no issues, in addition, it is functioning correctly. Now you have to view the report. To view the report is to view the webpage, and to view a web page means you need to either use "Anon" access or windows authentication. So you need a domain or local WINDOWS account to view the report. This account needs to be setup on the RS portal as a content manager role. *
You are dealing with two beasts, one is the database (db server) and one is IIS (web server) each serve a specific purpose. The database serves to allow you to pull data while the web server hosts the pages.
The reportserver database is very important, it keeps a listing of all your reports and the meta data associated with your reports in the database. It also stores job ids and subscriptions associated with your reports. Basically it is the backend database for all reporting services stuff like reports, datasets, and datasources. Think of it this way when you create a new "Report Project" you are allowed to create reports, datasets, and datasources. Without the reportserver database how would the system remember your datasets, datasources, and report names? It is the heart of rs.
your data set is not used to connect to the reporting services databse, it is used to connect to the database you are getting the data to display on your report.
Does that user exist on the database the report is accessing?