I have several SSRS reports that need to be transferred to another server. Currently, all reports and SSRS reside on the same exact server as SSMS and all databases. I was wondering if there is a simple way to essentially take everything I have on SSRS (All Reports) and transfer them along with their data sources to the new server that I have. I know downloading all reports and uploading them to the new server is an option but I was wondering if their is an easier/more logical way to go about this process. After completion, SSRS and the SQL Server will be on different servers but still able to work together.
I have had really great experiences with an old (2007) program called "SSRS Scripter" (from Jasper Smith). It seems like it has been absorbed into a newer product called SqlServerFineBuild (which I have never used). The original stuff is a little hard to find, but very nice to work-with, imo.
Microsoft also has another product called Reporting Services Migration Tool (free) https://www.microsoft.com/en-us/download/details.aspx?id=29560 It is a command-line util and isn't the easiest or most-helpful. It has a UI-mode, but it isn't very user-friendly.
Both of these will only extract report files and settings from an existing site. You still need to use VStudio (+ reporting add-in) (and then some RS project work/design/config) to re-deploy.
Related
We are using the IBM Cognos Report Studio for Making the Reports.
And we have 1000s of reports developed and using.
Now i need to fetch all the SQL queries written in these 1000+ reports.
For that at present i am opening the report studio for each individual report and getting the query.
But it is very tedious job and taking months to get all the SQLs in these 1000+ reports.
So i am looking for a way to get all these queries from database behind Cognos studio.
Does these report parameters (including the SQL) store in a Database or only in Contentstore?
If it store in DB then is it possible to access the Report Studio in a Database tool like Oracle SQL Developer?
So that i can fetch all the SQLs in one shot from the database table.
Thanks for the help!
My experience migrating from one reporting product to another is like what you are asking. I think I had 7000 reports that I was aware of plus many reports sitting on workstation hard drives. At some point along the way we realized that the new product had different features than the old one, so report redesign was a good option in most cases. It took 18 months once we actually started working on the reports. That was to replace the 700 "standard" reports. Users were on their own (with support from IT and subject matter experts) for their custom work. I now have about 19,000 reports in Cognos.
Except where the report developer wrote SQL in a SQL object in the Queries area, Cognos reports do not contain SQL code. Cognos generates the SQL at runtime based on the report spec and user interaction (what parameters they set, what page the opened, etc.). Short of writing your own report spec parser, duplicating the work that Cognos does for you, there is no way I know of to generate the SQL.
One possibility: I haven't dug too deeply into the Cognos SDK. There may be a method there to generate the SQL for each report. Then you can do it automatically. Be aware that for thousands of reports you'll want to run this process during non-work hours. It could run for hours and may use a lot of resources.
Another possibility: Turn on native query logging (Cognos Administration | System | All dispatchers | | Set properties | Settings | Logging | Check the boxes for "Audit the native query..."). Then have a person, a product like those from Motio, or a Cognos SDK program you create yourself run every report. Then you can get the SQL from the Audit database. Of course, the problem here is answering prompts. It will probably take a person to run these.
To add two columns to a list, or two data elements to a report or page header or footer, or two filters (I don't know what you mean by "clause"), you'll want to use the Cognos SDK.
Choose relevant examples of different types of reports.
Examine the XML report spec for each of those reports.
Determine how to identify where the new element should appear in the XML.
Write a program (probably in C# or Java) to use the SDK to...
inspect every report in your environment.
determine which pattern the report fits.
add the data elements.
save the report.
My team recently adopted Visual Studio's Web Performance Test/Load Testing solution. Our test plans are developed, and we preparing to begin collecting baseline performance and stress test results against an corporate MVC application.
Due to corporate network security "features", Microsoft's Agents/Controller on-premises test distribution solution is not an option. Furthermore, the TFS Virtual Lab and Azure Virtual Lab load test distribution solutions are also not viable options due to security infrastructure and resource limitations.
Because of these constraints, it seems our only option is to run a Visual Studio Load Test from each developer machine (at a coordinated time, through different internet connections). *If anyone has another solution, I'm certainly receptive.
Assuming we take this approach, I'm concerned the results Visual Studio stores in the "LoadTest2010" SQL repository will not accurately reflect the combined results of all developer machine's Load Test.
My questions are:
Is this approach even viable?
If so, what is the best way to combine the separate Load Test SQL repositories into a single SQL Database (keeping in mind connecting to a central SQL Server during test execution is not an option)?
Assuming we import all the testers' results into a central database, does anyone have an idea of how to report on composite test results? I'm assuming they'll all have different TestRunIds which seems that would break Microsoft's built in Views and Stored Procedures for analyzing test results.
Putting all the test runs into one database can be done by exporting the results from all the secondary places and importing them into one database. Use the Open and manage load test results commands. See https://sqa.stackexchange.com/a/14503/6752 for more details.
Combining the results from several runs cannot be done, as far as I know, within Visual Studio. However each "graph" can be exported to Excel where you can manually merge the results. The rows of each "table" (but, unfortunately, not the headers) can be copied and pasted into Excel.
I prefer the Export graph data to Excel and Export graph data to text (.csv) commands over the Create Excel report. (The two Export... commands are not available for tables.) The reason being that the "Create Excel report" requires Visual Studio to be run as an Administrator and I have not found a sensible way of letting the Administrator user have access to my non-Administrator load test database.
I am having to develop an application very rapidly. I have chosen SQL Server (2012) as the DB backend, and I will write all my stored procs, triggers etc in the backend.
However, for UI (logon, reporting etc), I am using Access 2010 for the frontend. I am new to both Access used earlier versions of Access waaay back in the day) and SQL Server (familiar with other Db's).
The goal is to have the database reside on a server and let clients connect with an instance of Access 2010 running locally on their machine.
I am looking for a quick tutorial that shows me how to use the SQL server objects from the Access frontend (I believe its called linking) - any link to useful resource would be very helpful, as I can't seem to locate anything useful (I may searching using the wrong keywords).
Assuming you built all the tables and data on SQL server, then in Access it is a simple matter to link Access to that database.
And to save development time, you can continue to use the Access simple approach of using forms bound to those tables. As long as you launch a form with some kind of criteria (say an invoice number), then that bound form will ONLY pull down the one record from SQL server into that form. (so need to write or use store procedures etc. for that form). And any triggers etc. you have built in SQL server will run without you having to do anything from the Access side.
So a plane jane form build in Access that is bound to a table of say 1 million rows in Access does not need any “special” code – just make sure you launch the form with the “where” clause that Access provides and the form will only pull + load the one record.
So 99% of the normal development process you used in Access in the past will continue to work. Using SQL server for the most part does not change much if anything in regards to building forms that edit such data.
However, for reports and some forms that query + search for data etc., or some VBA code that needs to “process” data, you are most free to call store procedures. You simply create a pass-through query in Access. The VBA code to use that T-SQL thus looks like this:
Currentdb.QueryDefs("MyRawt-sqlPassThoughquery").Execute
Or
with CurrentDb.QueryDefs("MyPass")
.SQL = "exec sp_myProc"
.Execute
end with
In the past for most access applications you likely used liked tables – those linked tables can be to a Access file (back end), or Oracle, or SQL server – how the actual application works and functions is really much the same for all cases. (so there not really a lot of “specific” things you need to know from the Access side – if you comfortable with Oracle, or SQL server, then using Access as a front end works just fine, and the typical development approaches used in Access will remain typical.
Here is an article that outlines the linking process:
https://support.office.com/en-us/article/Import-or-link-to-SQL-Server-data-A5A3B4EB-57B9-45A0-B732-77BC6089B84E?ui=en-US&rs=en-US&ad=US&fromAR=1
Keep in mind you will see MANY articles that talk about ADP projects - they have been deprecated since Access 2010, and I don't recommend using ADP projects with Access - so be careful, since many articles that talk about Access + SQL server are built around ADP projects which as noted should not be used anymore.
This office.microsoft.com article should give you a good overview.
With plenty of more technical information searching for "query sql server from ms access".
Don't mess about with linked tables. Use an Access ADP (Access data project), which is natively connected to SQL Server. Sadly this type of access file is being phased out but it is the optimal solution for an MS Access front end with a SQL Server back end
Pros and Cons of Access Data Project (MS Access front end with SQL Server Backend)
I'm working with WinForms a project that has a couple of oddball requirements. This is an existing business system that is installed in numerous locations under a fairly wide variety of environments. Part of this variety is a mixture of SQL Server versions, and--of particular importance--SQL Server Reporting Services versions. Everyone is on at least 2005, but about 50% of our users are on some flavor of 2008.
Unfortunately for me, I need to be able to run a client-side report that's written in 2008-version RDL. I can't modify the report in any substantive way at this point, so rewriting it in 2005-version RDL isn't an option. The catch is that this report (as it's written in 2008) requires the 2008 ReportViewer control. However, the 2008 ReportViewer control cannot connect to 2005 SSRS.
The solution that I've come up with is more than a little hacky, but it will alleviate 90% of the problems introduced. I've left the references pointing to the 2005 version of ReportViewer, and I'm modifying the application configuration on startup to add assembly binding redirection tags moving from version 9.0.0.0 to 10.0.0.0 for ReportViewer.Common and ReportViewer.WinForms if the user's target report server is running 2008.
As twitch-inducing as this solution is, it's working for me. The users running SSRS 2005 can still access their existing reports, just not the new one. The users running SSRS 2008 can access everything. My only problem is that I haven't been able to find a way to refresh the configuration data. I'm updating this info before any of the assemblies are loaded, but calling ConfigurationManager.RefreshSection("runtime") doesn't appear to have any effect. Once the app restarts, the proper assemblies are loaded, but I'd really like to be able to have this change take effect immediately.
Any thoughts on how I can force the runtime to reload the binding redirection information from the App.config file at runtime?
Once the AppDomain is created, the configuration data that affects binding is fixed. Which happens on the default CLR when the primary AD is created, before your code starts running. If you are really desperate then you could create a secondary AppDomain and give it a custom AppDomainSetup with another ConfigurationFile. And loads and run your regular startup code in that AD. Not exactly sure what kind of side effects this might have.
Our centralized IT department has suggested two primary ad hoc query tools for our general user base of approximately 200 staff members:
Microsoft SQL Server Management Studio 2008 (SSMS)
Microsoft Access 2003
Environment
The backend database is a read-only Microsoft SQL Server 2005 database.
The schema is 400+ tables; allowing access to the raw data for our general staff would be a disaster.
We will be building an "abstraction layer" over the raw data for our general staff to run ad hoc queries against.
The abstraction layer will most likely contain a number of views.
A number of users have basic knowledge in Microsoft Access; none have used SSMS.
Which of the above tools (or alternative) would be best for a decidedly non-techie user base of approximately 200 people? What are the pros and cons of each?
Also, the IT department has suggested teaching people T-SQL so they may use SSMS. Is this reasonable?
How about this one? i-net Clear Reports (used to be called i-net Crystal-Clear) has a powerful ad-hoc reporting component that is made to be an easy-to-use thing for non-technical users. Your users won't have to know anything about reporting at all. They simply select the kind of report, the data et voila there is a report suiting the needs.
The data abstraction can be done easily by creating so called data-views which can be designed by e.g. your administration. There are various ways to access the ad hoc reporting GUI. We have a web GUI, a Java Applet or a standalone Java program.
The end users will not need any training since the GUI is highly intuitive.
The views can easily be build by drag and drop in addition to setting datatypes, formats and so on.
All reports (depending on security settings) can be accessed via DAV our a report repository gui.
The server supports different security settings on a per user or per group basis.
The standalone report designer is free and fully functional.
Disclosure: Yep. I work for the company who built this.
Your "abstraction layer" is the right approach to take with Access. Create an MDB with the basic views required linked into it and distribute to the users. Allow them to create new queries and reports in their own MDB as required.
Now how you are going to stop them from running a Cartesian join on tables with a million records or more I'm not quite sure.
Microsoft have a free tool for business and end users which called "Report Builder". It supports the full capabilities of SQL Server Reporting Services. The good thing it is provides a Microsoft Office look-like user interface.
You can download latest version "Report Builder 3.0" from here
http://www.microsoft.com/download/en/details.aspx?DisplayLang=en&id=6116
And for more information about MS Report Builder check this link
http://technet.microsoft.com/en-us/library/dd207008.aspx
Attempting to teach "non-techie" people T-SQL to query a schema with 400+ tables probably isn't going to do well, unless they are limited to querying the views only, and the views hide all the ugly complexities of various joins, grouping etc.
Our company was in a similar situation where Access was used early on, and then we switched everyone over to use T-SQL and SSMS. IMO, this is the approach you'd want to take.
Again though, the success of this will depend on the quality of your views, or better yet, reports you provide your end-users.
Randy
I would look more into something like Stonefieldquery.com that is designed for non developers to build reports. Not that the report writer or query builder in Access is bad, but may be too much. I think they also provide a way to centralize reports and queries where they can be shared. Multiple people are not going to be able to open a single access file and create a report (I think query building is OK.).
Most will use the drag and drop capability, but about 5-10%will come thing a need for SQL and then you can take advantage of the "teachable moment" and get them some training.
Cons for Access certainly would be cost; SSMS should be free assuming you're properly licensed for the SQL server.
Depending on the actual needs, some users might actually be better off with Crystal Reports (never thought I'd say that), or Reporting Services.
you could create a series of sql server analysis cubes and have the users conenct to those using excel so that they can use excel's pivot tables.
Being a newbie at ad hoc reporting and doing the work myself, I used Izenda.com ad hoc reporting. It was very straight forward, and I could do it myself versus outsourcing.
Check SQLS*Plus - http://www.sqlsplus.com
I found SQLS*Plus to be a very effective command line SQL server reporting tool - this is a free tool (for personal use) and allows me to generate reports with the titles, headers, in HTML and CSV formats, format columns in custom masks, set report length, pagesize, etc. As I understand it is very similar to very well known Oracle SQL*Plus reporting tool