We deployed a VB.Net application on a customer's computer that contains SSRS reports.
The application connects to the SQL Server database in the app without any problems. We installed SQL Server Data Tools so we could deploy the reports (rdl) and data source (rdl) files up to the report server. These deploy without any problems.
In SQL Server Data Tools we can "Preview" the reports without any problems as well.
We do run into a problem when attempting to view the report from Internet Explorer (run as an administrator).
We get the following error:
Cannot create a connection to data source 'DataSourceReports'
(this is the name we used for the TargetDataSourceFolder)
error:40 - Could not open a connection to SQL Server
We also get the same error when the app we deployed runs the reports.
Please let us know what is not set up correctly on the SQL Server side.
A likely possibility is that you are experiencing a double hop authentication problem. It's not clear from your explanation, but is the SQL Server database on a separate server from the report server? If so, then your credentials allow you to connect to the report server but Windows integrated security does not pass those credentials on to the SQL Server database if you are using NTLM on the report server. The report server tries to use Kerberos on your network to authenticate by way of ticketing to the SQL Server database, but you must have this configured correctly on your network. See this article if you want to use Kerberos: http://technet.microsoft.com/en-us/library/ff679930(v=sql.100).aspx.
Another (easier) solution is to open the data source on the report server and change the authentication to use stored credentials. Make sure the credentials you use have read permission on the SQL Server database. The downside of this approach is that you cannot use row-level security in your report by user unless you design your report to capture user information and set up the query or a filter on the dataset to restrict data by user. If that's not a concern, the stored credentials are easy to set up and maintain - and you're going to have to do this anyway if you want to use caching, snapshots, or subscriptions. For more information on stored credentials, see http://msdn.microsoft.com/en-us/library/ms159736.aspx.
Related
I have an AWS RDS (PostgreSQL) that is inside a private network - only accessible via a VPN and Bastian Host.
I am able to establish connection from PBI Desktop to "PostgreSQL-RDS Instance." By creating SSH tunneling from my Laptop (localhost) to Bastian Host using ODBC Driver. With this approach all the data is imported onto PBI desktop(import mode).
But our requirement is to establish connection through a direct query to refresh data real time and generate the Reports Dynamically which I am not able to.
I entered the database credentials into the Power BI desktop tool, and it not working correctly in the power bi desktop, getting a Timeout Error.
I must use direct query, I can't use import.
Any help is appreciated.
An exact error that you are getting would help get to the root cause of the issue. However, a few basic troubleshooting steps that I'd suggest are:
Ensure that you have a compatible version of the software installed on your machine such as the Npgsql-4.0.9. AT times the latest version of the software usually causes issues.
Ensure that you remove the semicolon at the end of the query.
Once you get the query running successfully on the desktop version, when you publish it to the web version, the visuals will not be able to connect to the database unless an on-premises data gateway is setup. To do so, more details on setting up a data gateway to automatically refresh the dataset for the power bi web version are here:
Refresh AWS RDS database from Power BI Web you are successfully able to query directly
I'm using Power BI version 2.84 to connect to Postgresql server. In PBI desktop everything works fine, I can connect to the server, import and refresh data smoothly.
However when I publish it to PBI server, I can't refresh it anymore due to 'encrypted connection'. I have checked all of my connection settings and make sure they are not encrypted at all but the problem is still there.
Please let me know if you have any solution for this.
Cheers
I assume you are using direct query?
If you want to use direct query you will need to set up On-Premises data gateway.
on premise gateways
And then you should add gateway cluster in PowerBI web version gateway cluster:
Data gateway
I think everything is quite straightforward here.
But do you need direct query? If you are ok with refreshing your data a few times a day, you could set up a ODBC connection (when importing data, choose ODBC option not postgresql).
You would need to set up ODBC drivers, (Control panel -> Administrative tools -> Data sources) And create a new one (you should download Postgresql ODBC driver if you have none)
Then you also need to create On-Premises data gateway and set up refresh intervals.
we are using 2018.3 version of Tableau Server. The server stats like user login, and other stats are getting logged into PostgreSQL DB. and the same being cleared regularly after 1 week.
Is there any API available in Tableau to connect the DB and take backup of data somewhere like HDFS or any place in Linux server.
Kindly let me know if there are any other way other than API as well.
Thanks.
You can enable access to the underlying PostgreSQL repository database with the tsm command. Here is a link to the documentation for your (older) version of Tableau
https://help.tableau.com/v2018.3/server/en-us/cli_data-access.htm#repository-access-enable
It would be good security practice to limit access to only the machines (whitelisted) that need it, create or use an existing read-only account to access the repository, and ideally to disable access when your admin programs are complete (i.e.. enable access, do your query, disable access)
This way you can have any SQL client code you wish query the repository, create a mirror, create reports, run auditing procedures - whatever you like.
Personally, before writing significant custom code, I’d first see if the info you want is already available another way, in one of the built in admin views, via the REST API, or using the public domain LogShark or TabMon systems or with the Addon (for more recent versions of Tableau) the Server Management Add-on, or possibly the new Data Catalog.
I know at least one server admin who somehow clones the whole Postgres repository database periodically so he can analyze stats offline. Not sure what approach he uses to clone. So you have several options.
I've written a web app in ASP.NET that stores all of it's data in SQL Server 2008r2 and runs everything via stored procedures. The app is collecting data for a department who wants 2-3 pieces of that data pushed to an old app they use which has a Microsoft Access 2003 backend (.MDB file). My thought was to create a linked server to Access so my app can push everything to SQL server and it can handle it from there (seemed simple enough). Based on info from MSDN (here and here), I was using the following SQL command to create the linked server:
EXEC sys.sp_addlinkedserver #server = N'CMPtesting' ,
#datasrc = N'\\srv.local\SHAREDOCS\MPS\CMPdata.mdb' ,
#srvproduct = N'Access' ,
#provider = N'Microsoft.Jet.OLEDB.4.0'
This completes successfully, and I can see my CMPtesting server listed under Server Objects -> Linked Servers. However, if I try to verify the server using this:
SELECT name FROM [CMPtesting].master.sys.databases
or even just view the tables, I get an error:
OLE DB provider 'Microsoft.Jet.OLEDB.4.0' cannot be used for distributed queries because the provider is configured to run in
single-threaded apartment mode. (Microsoft SQL Server, Error: 7308)
Researching that error led me to "SQL to Access linked server" which suggested installing some different Access drivers and then using #provider = N'Microsoft.ACE.OLEDB.12.0' instead of the Jet driver. Again, this completes successfully, but attempting to view the tables produces a different error:
Cannot create an instance of OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "CMPtesting". (Microsoft
SQL Server, Error: 7302)
I know this is not simply an invalid driver error, because if I just make up a provider name I get this instead:
The OLE DB provider "foobar" has not been registered. (Microsoft SQL Server, Error: 7403)
I'm not sure what else to try because all my searches just turn up more rehashing of how to run sp_addlinkedserver without any additional details or help with these errors.
While deploying reports I am getting login prompt asking for the User Name and password. I have tried providing all possible id and passwords but no use. I can access both the Report manager url and ReportServer url but if I start deploying reports through SQL Server Business Intelligence development studio I am getting the above mentioned prompt. Please let me know how to avoid this.
Make sure that the server on which you are trying to deploy the Reports, you must be under the group which has the following Role assigned.
Browser, ContentManager and Publisher.
goto Start menu ->Microsoft SQL Server 2008->Configuration tools ->select Reporting services configuration manager ->Connect Report server ->Select Database from the left side options -> Current Report server Database -> Click Change Database ->Choose Existing server Database ->Test the connection ->Next -> Select Report Server as Report server Database.
And goto Select Database from the left side options -> "Current Report server Database Credentials" ->select Authentication type as integrated security and Test connection -> select Authentication type as Service credentials.
I hope it will resolve the problems
Best verification is to make sure you are deploying the new reports to your report server link. And not to the link which corresponds to the report manager. I was running across the process of deploying reports after ages, and I observed this problem when the report server target link is not correct.
I use VM for SSRS development.. and it's not a member of the domain where the SSRS Service lives.
I was able to easily eliminate prompts when deploying reports.. by setting up a LOCAL user account on the SSRS server that used the same username / password as what I was using in my VM.
I had the same issue, but this worked for me: When deploying from SQL Server Business Intelligence Development Studio, you must be running it as Administrator. ie. Right-Click and select 'Run as Administrator'.
This is possibly because if you are not running it with elevated privileges, then it can't do the Impersonation to login to the server.
Using web services URL in TargetServerURL instead of Report Manager URL.
Goto Reporting services configuration manager, connect SSRS server then go to "Web service URL" in right hand side you will find a link like as http://server//reportingServer. Copy the url.
Now open Business Intelligence Development Studio. open SSRS project.
Goto Project menu and click on properties, in property page Paste copied URL in TargetServerURL. Now Rebuild the project and Deploy. Credential will not appear and Deploy succeeded.
When moving (deploying or copying) an RDL file from one location (development) to another (production) the report may loose track of it's shared data source, at which point the data set will replace the original node with a new node that instructs SSRS to demand credentials.
In the report that is persistently demanding credentials if you right-click in solution explorer and select 'view code' the .rdl will open in an xml reader window. If your mark up contains a reference that looks like:
<DataSources>
<DataSource Name="YourDataSourceName">
<ConnectionProperties>
<DataProvider>SQL</DataProvider>
<ConnectString>Data Source=<i>your-server</i>;Initial Catalog=<i>your-db-name</i> </ConnectString>
<Prompt><b>Enter a user name and password to access the data source:</b></Prompt>
</ConnectionProperties>
<rd:SecurityType>DataBase</rd:SecurityType>
<rd:DataSourceID>e2f9f97c-GUID-GOES-HERE-395c383c1da2</rd:DataSourceID>
</DataSource>
</DataSources>
If this is what you find in the xml/rdl this is likely your problem.
Make sure you have a Shared Data Source that works as expected, you may have to build a new report based off of this that does not prompt for credentials.
In a report that does NOT ask for credentials, open the RDL using 'view code' option.
Select the relevant xml node (under ) and copy the node, it should look something like:
<DataSource Name="YourDataSourceName">
<DataSourceReference>YourDataSourceName</DataSourceReference>
<rd:SecurityType>None</rd:SecurityType>
<rd:DataSourceID>19f0a78a-<b>GUID-GOES-HERE</b>-0e277b3b153f</rd:DataSourceID>
</DataSource>
In your target report replace the node with the one you copied.
(worth noting that when you change the 'rd:SecurityType' from 'Database' to 'None' you are NOT removing security, you are merely passing responsiblity for authentication from the report's dataset on to the shared datasource. (Security is born by the connection rather than the query)
I had the same problem, it was due to the wrong spelling of the TargetServerUrl in report project properties, make sure that it meet the same name in the Report Server Configuration Manager: