Friends I have a problem with SQL Server Reporting Services ..!!!
I have some reports that show no data, the reports are on a separate server from the server that contains the database, the Data Sources of the reports is well configured.
Stored procedures are executed while the server (display data)
users have the necessary permissions.
What is the problem ..? Thanks
Also, look at reporting services logs. they all end in .log, and begin with Report. I forget where they are on the server, but am pretty sure they are under the program files directory for mssql, just as you would find logs for sql server.
It sounds as though the definition of your data sources in production may be different from that in development. Have you tried redeploying your data sources?
You should be able to access the Database on a server separate from the report server. That all sounds good. When you run the Reports in Visual Studio Preview mode....do you see any data?
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.
Thanks in advance for any help.
We have a particular database on a SQL Server 2012 box along with about 20 other databases.
What I require is a method/script/audit (open minded about the solution) that will simply track anyone who logs in (successfully / unsuccessful) to this one particular database on the server (the single database is the key as the end user does not want information on any of the other databases that sit on the server), it also has to log time the attempt was made and it must track the logins via SQL Server or the application itself that is attached to the database.
Once we have this information we need to simply store that somehow. I say somehow as the storing part depends on the solutions recommended to me, so I’m open minded about this too.
Any help would be great as I'm scratching my head on this one.
There's actually a tool built into SQL Management Studio for this.
Please see the attached link for Configure Login Auditing
Once it has been setup, all events will be recorded in the error log.
I'm currently working on a reporting tool for a company that conducts the same survey at different clients. So the analysis and report would be the same, except for the conclusions. The ultimate goal of the project would be a tool that automatically extracts, analyses the data and creates the report. SQL Server and Visual Studio are mandatory programs.
I'm completely new to all of this except for the SQL-language. After reading up on this and asking around the usage of stored procedures seemed the best option. If I interpret correct these should be stored in SQL Server and could then be envoked in Visual Studio
However, my problem is, I can't figure out how to connect to the external ODBC-server that holds the data in SQL Server 2005. It seems to me there is no way to connect to a remote server in SQL Server 2005. On the other hand, in Visual Studio 2005 I did manage to connect and extract data from the server.
Is this the right way to achieve my goal (repeatable/automated report)? If so, what am I doing/thinking wrong? If not, please enlighten me.
Thx in advance
Another way to do this is to use bcp...you can check this article to see if there are any answers here for you. There would be no remote server connections if you are able to run the command and the local box that contains the sql server.
You might be able to set up a linked server in SQL Server 2005 to connect to your remote server/database.
I am a beginner user of SQL Reporting Services. I wrote a few reports. They all use stored procedures on my development SQL server. Now I want to deploy them into production, and repoint the datasets and datasources to my production SQL db.
How best to do this? Can I just do a global change from development_server_name to production_server_name?
Thank you.
You set up your reports to use a shared data source. The data source is published along with the reports. You deploy your datasource, then go into SSRS management URL and modify the newly deployed data source to point to a the production server. All subsequent deployments will preserve this change, so you can now deploy modified and new reports at leisure, they will automatically pick up the redirect to the production server once they are on the SSRS site.
Of course, if you used stored procedures, you need to deploy those as well on the production server.
If you didn't used shared data sources on the reports, then lear your lesson, go back and change them to use a shared data source, then deploy.
I want to send SQL server Dashboard & Health Report to my client on daily basis, so is there ant script / tool to generate report for sql server 2005.
You can download the Performance Dashboard reports and then edit them for use inside reporting services manually, or use them as they are provided.
http://www.microsoft.com/downloads/details.aspx?FamilyId=1d3a4a0d-7e0c-4730-8204-e419218c1efc&displaylang=en
These install the reporting services RDL files to c:\program files\Microsoft SQL Server\90\Tools\Performance Dashboard, and there is a setup.sql script that contains the actual TSQL objects that are used by the reports. This can easily be the basis for what you are trying to do, and the RDL files can be imported into Reporting Services to allow subscriptions to automate delivery. There is a known issue with one of them where a datediff using milliseconds overflows the int datatype but you can find a fix to this on Robs blog post:
http://blogs.technet.com/rob/archive/2009/02/18/performance-dashboard-reports-for-sql-server-2008.aspx
You don't really have to do a lot of excess work reinventing the wheel if you start off with the basic Performance Dashboard reports provided by Microsoft with SQL Server 2005 SP2 Feature Pack and then doing small customizations as necessary to meet your needs.
This sounds like a perfect job for SQL Server Reporting Services.
As to the queries that you need, that will all depend on what you want to show.