I have a set of reports on a SSRS 2012 server and they work fine. We are moving to a new server, so I changed the server in the report property and redeployed. The reports are on the new server, but none of the shared datasets and data sources work anymore. I get this error:
Cannot create a connection to data source ' Data source for shared dataset'. (rsErrorOpeningConnection)"
All the datasets and data sources use predefined credentials. I look at the reports in Visual Studio and I can connect just fine. Can anyone tell me why deploying to a new server breaks everything?
If your data sources contain stored credentials, you need to backup the encryption key from the original server and restore it in the new one. Otherwise those shared data sources won't work. If this is the case and you know the credentials, you can edit manually all those shared data sources.
Credentials stored in embedded data sources won't work as well if you don't restore the encryption keys.
You can query the SSRS database in several ways to discover all those Shared Data Sources and embedded ones, you can find them in this site. One example could be
Listing all Data Sources and their Dependencies (reports, items, etc) in SQL Server 2008 R2
Hope this helps
Related
I'm trying to deploy an SSRS report to a remote server (that is not on my network). I'm not sure how to do this. For a machine on my network, I would just change the TargetURL, but I'm guessing there should be somewhere that I can associate credentials to deploy to a remote server, but I'm not finding it.
I know this is an old post but if someone is wondering about the same question.
I am using vs2017 enterprise. So when you configure your remote url and folder name and everything is perfect to build your project, you hit F5 or deploy your project. Upon successful building vs will prompt you for your report servers credential. Then you do the usual and vs will do its own job. In a moment you will be able to access your report.
Just read about the permission requirements before you try it.
Hope it will help someone.
Thanks
I face a similar issue delivering reports to various servers (customers and dev,qa,staging and production.) In visual studio the best way to do it is start a new project for the new server and import the new reports into it. You end up with a new project for each server.
I found TFS / VS unwieldy and my workflow to manage it unfortunately is doing it manually, or using one of a few open source report uploading tools (there are powershell scripts to do it but I find the tools are more user friendly.)
Best thing to start with is doing it manually; which will sort your initial problem.
Save the file out of your report writer to disk.
In Internet Explorer log into the Report Manager of the remote server http(s)://remoteservername/reports and navigate to the folder you want. Then upload the report.
When its uploaded you may need to fix the connection to the database.
Once you get used to doing this you can use a tool like reportsync to easily and quickly move reports between servers.
So my problem is that on an already working instance of SQL Server 2008R2, a former colleague of mine installed a new instance, apparently with the same name and leaving us now with an empty Report Manager. The URL for the old one still works, but it only shows me the file structure for the old Report Manager.
Is there a way to somehow extract the old RDLs (considering it has no graphical interface anymore) so that I may load them to the new one? Or alternatively, set the ReportServer service to use the old instance in order to download the RDL files?
Thanks in advance.
I can think about a couple of options:
Download through Report Builder
It sounds like the old ReportServer URL is available? That's something, at least.
One option that might have the least impact is connecting to the old ReportServer through Report Builder, opening the RDL files then saving them to the location of your choice.
Connect to the ReportServer:
Navigate and open the file you need.
Click Save As to save the RDL as required.
Start/restart different instances
Based on your description, it sounds like both instances are trying to register the same URL.
If possible, I would stop both instances, then restart the old instance which has the RDL files you want.
Hopefully this will allow the old instance to register its URLs successfully and allow you to connect to the old Report Manager URL and download the RDL files.
You can check the different URLs each instance is using through the Reporting Services Configuration Manager application:
I'm fairly new to SSIS and am having trouble figuring out something that seems like it should be straight forward:
On server A, I have 10 files in "C:\SourceFiles\Patients" (these files are PDFs). I know the names of these 10 files and they won't change. Also, there is a server B which is the DB server and is where the SSIS package will be located. My goal is to loop through a DB table containing patients, add some patient data to the 10 source files (renaming the file) and then save this new file to server A.
I have most of this running already. Currently, all of this is happening in a script task using ADO.NET for the DB access (I'm already accessing the DB table on server B) and I'm accessing the source files on my local C drive.
I am having trouble figuring out how to specify server A in the Package Configuration for the source files. I have a file connection which specifies an existing folder (C:\SourceFiles\Patients), but it only specifies the location of the folder NOT the server. How to I specify server A for this file connection? Or, how do I use this file connection with a server A connection? I'm having real difficulty grasping this for some reason!!
The technologies I'm using are:
Visual Studio 2008,
C# in the SSIS script task,
ADO.NET in the SSIS script task and
SQL Server Management Studio 2008 (SSIS package will be imported here).
Thanks for pointing me in the right direction!
I see some issues with what you are trying to do.
PDF is an image format (an image of a document) and as such is not easily manipulated by SSIS. Generally if you are acting on a file from within SSIS, it would be a flat file of some sort, like a CSV or some other text format.
Using a script task to do all of your work within SSIS is failing to use the power of SSIS properly. If all you have in your SSIS project is a script task, you should just be using C# or VB.net directly and not involving SSIS in your project at all.
That all being said, you should access your files on server A using UNC (Universal Naming Convention) paths. You will need to pay close attention to your permissions within SSIS to make this work. When an SSIS job runs, it runs under a specific user, usually the SQL Server Agent user, and that user will need permissions to access the folder on server A remotely. When all of these permissions are set correctly, you can use something akin to \\ServerA\ShareName\Patients\ as the pointer to your directory with pdf's in it.
I get the following error when trying to run reports:
The current action cannot be completed. The user data source credentials do not meet the requirements to run this report or shared dataset. Either the user data source credentials are not stored in the report server database, or the user data source is configured not to require credentials but the unattended execution account is not specified. (rsInvalidDataSourceCredentialSetting)
By the way I am running it from VS2010 with SQL Server 2008 Reporting Services.
How do I solve this issue?
Yes, I've seen this. You can set the Credential and Connection Information such that a report is run impersonating the unattended user account. This article explains how to set up this type of report running. This setup is especially useful if you want to use the credentials inside a dynamic connection string (for example when you need to insert the credentials through a parameter).
If you don't want to run using the unattended user account, you should review your DataSource and connection string as defined in the report. Perhaps play around with the settings and different configurations for the datasource to create a different setup. The above links should be a start for some documentation.
In my case, it was because of some deployment parameters.
Go to Project Property by Right-clicking at the Project name in Solution Explorer and select Properties.
In Configuration Properties > General, change OverwriteDatasets and OverwriteDataSources in Deployment section to True for both parameters.
Click OK.
in my case, replacing linked server connections with local (fetched from remote locations and stored in local tables)data connections helped. we also checked this for ALL subreports/linked reports and it worked fine.
This happened to me today, it was because I was using the wrong datasource in my report. So I changed the datasource manually in Report manager and it worked. I guess another choice is to redeploy your report with the correct datasource.
This happened to me today. I am using Visual Studio 2019 for creating the reports for SQL Server 2014.
One of my reports had an embedded data source, but it was unconfigured/not configured properly. (You can see embedded data sources in the "Report data" pane under "data sources").
However, the embedded data source wasn't actually being used. I created the embedded data source earlier for debugging and forgot about it.
After deleting the unused embedded data source, the error went away.
This is from Microsoft:here
User Action
Change the settings for the current report so that it can run unattended, and then try to create the subscription or other scheduled operation again. Use the following steps to configure a report to run unattended:
1) Go to the Data Sources properties page of the report that you want to automate.
2) For the Connect Using option, select Credentials stored securely in the report server.
3) In User Name and Password, type credentials that can be used to access the database. If you are using SQL Server as the data source, the user name must be valid for both logging on to the server and for accessing the database that contains the data for the report.
4) If the user name and password are credentials for a Windows account, select Use as Windows Credentials. If the credentials are for a SQL Server user login, do not select this check box.
Do not select the check box Impersonate the authenticated user after a connection has been made to the data source, regardless of authentication type. This option cannot be used for reports that run unattended.
In my development environment, every time I reboot windows (which must be done at least daily for me), all of my Shared SSRS Datasources lose their credentials.
Currently I have them set up to log into the database using a fixed credential, but on reboot all the datasources pop over to using no credentials. Granted, it's only in the dev environment, and I can just check out/update the datasource/check back in and it will work fine... until I reboot again.
FYI, I've been using these Shared Datasources for at least 2 years and no problems, but in the last month or so, it's been a recurring daily problem.
Help?
I'm assuming you are talking about the Shared Data Sources in a Report Server project in Visual Studio, as opposed to a Data Source created directly on Reporting Services. The latter, the data is stored all in the ReportServer database that was specified when setting up SSRS.
Now, as for the .rds file used in Visual Studio, if you open the file up in a text editor, notice that the username and password is not stored in the file. It is actually stored in the .rptproj.user file. So, check that someone didn't remove the .user file from source control (.user files shouldn't be in source control, but in your case...).
This is scenario is testable by entering your credentials, saving all files, and exiting Visual Studio. Find and delete the .rptproj.user file, and open your Report Server project up again and see the credentials gone!
A work around is add the "User ID=user;Password=pass" as part of the Connection String. When the .rds is opened up, the Connection String won't show this portion, but the Credentials tab should have the right values.
Could this be related to the boot order of services on your machine.
Just a guess: Maybe there is new functionality in SP3 that checks if the connection credentials are valid. If they are not valid they are cleared.
The problem would then happen if this check is done before SQL server has had time to start. This would explain why they are cleared when the machine restarts.
I have recently experienced the same problem, but I can't connect it to a reboot. It seemed to happen when I checked the solution from source control - we use Team Foundation Server. After disabling the service account a bazillion times, it somehow healed itself and began behaving. I found this post and checked my project folder for the rptproj.user file that benson mentioned, and it has a modified date of the day I had problems, but a create date of close to what I can remember as having created the project, so I will pay attention to this in the future.
Did anyone come up with anything new on this issue?
I realize you may have read this already, but something here could help? http://msdn.microsoft.com/en-us/library/ms159846.aspx
I would pay attention to how the SSRS was installed and also what accounts the servies run as, as well as an domain logon policies.