I have some records in SharePoint server. I have to create some reports using SSRS. I am little bit confuse that I used SharePoint list for creating reports or I used separate database for creating SSRS report. Please let me know which one is best way for creating SSRS report, using SharePoint list or using separate SQL Server database.
Thanks.
If you're dealing with relatively small datasets, it's probably fine to get data from SharePoint lists but this is not supported directly until SSRS 2008 R2. However, you can try to adapt the technique described here for earlier versions:
http://www.codeproject.com/Articles/24469/SQL-Reporting-Services-data-from-SharePoint-lists
This example explains how to do this with SharePoint 2007 - I'm not sure what you'd need to do to make it work with SharePoint 2010. You don't indicate in your question which version of SharePoint you're using, so I'll throw it out there just in case it's helpful.
If you're using SSRS 2008 R2, then you have a built-in SharePoint list source which you can learn about here: http://www.mssqltips.com/sqlservertip/2068/using-a-sharepoint-list-as-a-data-source-in-sql-server-reporting-services-2008-r2/
I would consider it a reasonable source if the reports run fast enough. If they don't, you might need to set up a separate database so that you can tune the queries and/or the data to get better performance.
Related
I am new to Microsoft BI and I am wondering if you need SSRS installed in order to deploy a PowerView report to SharePoint. My datasources will be Excel files.
I know my company has a SharePoint (don't know yet which version). I don't think SSRS is installed, can I still deploy a PowerView report on the SharePoint? Or is SSRS needed for this requirement? Datasource will be just excel files.
No, you need SSRS in SharePoint mode in order to use Power View reports. You will also need to have the Reporting Services Add-In for SharePoint and PowerPivot for SharePoint installed and configured. Your SharePoint instance will need to be 2010+, depending on your version of SQL and Excel.
When deployed in a SharePoint BI Centre, Power View utilises components of the SSRS installation for the report, and uses the PowerPivot server (essentially an SSAS Tabular instance) to store and process the data model.
If you think about it, it makes sense, since a Power View .RDLX file is essentially a zip file containing an SSRS report and some other stuff. Dan English wrote a good article exploring it.
MSDN has a good deployment checklist that I've used myself in the past.
I've been trying to figure out if it makes sense to use SSRS 2012 with PowerView vs using SSRS 2008.
I've following questions:
What's better in SSRS 2012 without PowerView(ie without using Sharepoint)?
What edition of SharePoint you need to make PowerView work for SSRS 2012?
Does it make sense to learn and use Sharepoint if you can barely utilize the pluses of SharePoint or PowerView instead of SSRS 2008 or SSRS 2012 without PowerView/SharePoint?
I can address the overall question but not the first two bullet points specifically as I have not used Sharepoint enough to give the version differences on it.
Powerview from everything I have ever done is a dll that allows a report like object to be created as an add on to Excel. These objects can then be hosted in Sharepoint in a library. The downside is you need to have the dll's and the add on to Sharepoint to use it. As far as I know you are committing to user's going to SharePoint with this option. They do make it kind of neat though as you generally make what I believe they call a 'PowerPivot' which is just like a client dataset made in the Excel file that you report off of. This option is good for a shop that works with Sharepoint Extensively. I have not heard of too many places using it for client facing front ends or external reporting.
SSRS's newest invocation is SSRS 2012 which from everything I have seen in development is the EXACT SAME THING as SSRS 2008R2 except they put a 2012 in the namespace. There may be minor tweaks on naming and intellisense and under the hood things but the langauge is almost identical. Saying that SSRS 2012 is free with advanced tools for SSRS now and can also port to most front ends you would want: HTML in a form talking to it's service, ASP.NET, a client app like WinForms or WPF. You basically created and host reports and you can access them anywhere.
The real question for most people is: "Which reports look cooler and are easier to use?" I would go with SSRS, but know it is more of learning curve of understanding SQL and a little bit of xml and Visual Studio(very light). However Powerview is more graphical with it's parameters and options to an end user and has highlighted some things it can do with mapping interactivity that SSRS cannot do. The biggest detractor for SSRS IMHO is two things:
It is not event based at all. This shows up whenever you are doing mapping or something you want to zoom or perform actions that then produce other actions or 'events'. It can do a 'click' do something but NOT on the same page necesarrily. Usually you trick it to open a new form for a 'drill through' or use javascript to trick it to do a cheap man's version of hover over reporting by opening a form when you click.
To continue off of one it is this way on default behaviors of values of parameters and passing them down. Everything with SSRS is made to happen once at execution and then anything else happens to leave the form, not stay there.
Saying all that I still like SSRS better. It tends to handle large datasets when PRESENTING them better. Not necessarily all the time at getting them as the PowerView optimizes the set locally but at the expense of huge excel files. Sort of like psuedo cubes. They are fast, but you have a big file size for that expense. But with a lot of data they tend to be clunky as they are Excel based. Yes the query at the end will return faster but you have a huge file. When in reality if you are skilled at SQL SERVER you could be creating a Report Warehouse that is well indexed off of metrics and a cube as well to do this stuff for MANY REPORTS. SSRS is more for developers of TSQL, versus PowerView is more for analysts that know a little SQL but love Excel. They want a 'Select * from (table)' and then form the data, not they know how to do advanced groupings on their set first and then want to present a finished product to someone.
To answer your questions one-by-one:
What's better in SSRS 2012 without PowerView(ie without using Sharepoint)?
In "native mode" SSRS, i.e. a non-Sharepoint installation, there's not an awful lot of new stuff. The renderer now supports Word/Excel 2007-2010 format (i.e. DOCX, XLSX) output and the addition of native mode Data Alerts seem to be the only real difference to 2008 R2.
What's new in SSRS 2012
What edition of SharePoint you need to make PowerView work for SSRS 2012?
Unfortunately, you need SharePoint Enterprise Edition.
Does it make sense to learn and use Sharepoint if you can barely utilize the pluses of SharePoint or PowerView instead of SSRS 2008 or SSRS 2012 without PowerView/SharePoint?
If you are only looking at SharePoint to host/share PowerView and SSRS, it's definitely not worth the investment, in my opinion. There are other alternatives now that are much more accessible to smaller organisations, or those who don't want to invest heavily in SharePoint infrastructure.
PowerView is built in to Excel 2013, which allows users to build their own PowerView reports. Until recently though, there was no way to share these other than passing the Excel files around. However, Microsoft have now released the preview of Power BI, which is an Office 365 based BI platform, essentially providing SMEs with a cheaper and easier alternative to setting up a SharePoint server, and allowing self-service BI. It enables users to upload their Excel files containing PowerViews and share them with their organisation. You can also share other creations, such as Power Query projects, and internal data sources. All without an on-site SharePoint installation.
If you really want to try out PowerView, I'd suggest getting yourself a trial of Excel 2013, or sign up to the Power BI preview and give it a shot. Personally, I wouldn't recommend upgrading to 2012 purely to upgrade your SSRS installation, the new native mode features aren't really worth the cost/effort. If you're looking at upgrading the rest of your infrastructure though, (SQL, SSAS, SSIS) then it's definitely worth doing.
also wanted to add that if your deploying from VS to sharepoint directly; you versions have to be close together i.e. 2008 ssrs on sharepoint 2009 etc. You may not be able to deploy a rdl built in 2008 on sharepoint 2012,13. We had similar issues at one of my previous projects.
I have provided users with a view of a large data set through Sql Server Analysis Services, and they find it very easy and intuitive to manipulate.
However, I am now being asked to provide them with access to smaller and smaller data sets, for which Analysis Services is not a great fit. The reason is that they like the ease of manipulation of the data, and it's pretty flexible in it's presentation of the data.
Also, many of the data sets are available to retrieve via a REST API, in a tabular form, which I'd prefer to use rather than providing database access.
Can anyone recommend any tools or libraries (ideally open source) which:
provide an SSAS-like interface for building up a pivot table (with attributes grouped together rather than in a flat list)
can retrieve their data from a web service rather than a traditional DB?
(NB I thought about trying powerpivot, but I'm not really sure what I'd be getting myself into, so if anyone has any experience of using this I'd be interested to hear)
Powerpivot is an excel plugin for excel 2010 that uses the vertipaq engine. It has a language called DAX that is very similar to MDX,
more information can be found here
If you wish to use PowerPivot, you have three options:
1) Use PowerPivot from within Excel (it's a free add-in - be sure to install the edition that matches the edition of Excel you have, i.e. 2007 or 2010 and 32-bit or 64-bit). You are using the resources of the client machine in this configuration.
2) Use PowerPivot for SharePoint - this requires SPS 2010 Enterprise. It allows you to host (render) the PowerPivot workbook using resources from the SPS server.
3) Use SQL Server 2012 SSAS installed in Tabular mode (to build a BISM). BI Semantic Models are PowerPivot models which are hosted on a SQL Server instance. This requires a full SQL Server licence, so it's certainly not cheap. However, here you have the greatest flexibility for resources, as you can use (control/monitor) the resouces of your server.
For more information see my deck on the BISM on SlideShare.
Are there any tools on the market that effectively analyze data in SharePoint lists? I have a client looking to analyze and report on employee performance data stored in SharePoint.
Does SSRS give you anything useful?
Do you just need to report the data, or do you require complicated aggregation?
Nintex reports on SharePoint itself (and is acually quite cheap). The way the question is stated the report might be about employee data in a sharepoint list so SSRS does make more sense.
You can also look at some the BI features that come with MOSS Enterprise such as the KPI web part, scorecards, reports, Excel services and dashboards.
In addition to SSRS you should also consider using either Excel or Access to run reports :-
Analysing SharePoint Data in Excel
(Look for the section titled SharePoint-to-Excel and Data Synchronization)
How to Link SharePoint Server 2007 Lists with Microsoft Access 2007
Page currently borked, cached version http://209.85.229.132/search?q=cache:YnuTwWha77UJ:sharepoint.microsoft.com/blogs/GetThePoint/Lists/Posts/Post.aspx%3FID%3D68+connecting+access+to+sharepoint+lists&cd=5&hl=en&ct=clnk
Remember that you can also access the list data as XML so any 3rd party BI/reporting tool that can call one of SharePoints web services and manipulate the resulting XML could also be used - there are must be hundreds of contenders here.
The best tool to use depends upon many factors such as what you may be familiar with, the complexity of analysis you need, if you need static or dynamic reports (drill down etc). BI & Reporting tools are a huge area!
Finally if you need fairly simple PivotTable/crosstab type functionality then this CrossTab web part may be suitable (disclaimer - its sold by my company)
Edited:
What is the easiest way to scrape extract SharePoint list data to a separate SQL Server table? One condition: you're in a work environment where you don't control the SQL Server behind the SharePoint Server, so you can't just pull from the UserData table.
Is there there any utilities that you can use to schedule a nightly extract?
Is Microsoft planning any improvement here for "SharePoint 4"?
Update Jan 06, 2009:
http://connectionstrings.com/sharepoint
For servers where office is not installed you will need:
this download
There is a SSIS SharePoint task you can use to grab the data info a regular dataflow:
http://www.codeplex.com/SQLSrvIntegrationSrv
Scraping? As in screen scraping? Are you serious? ;)
2 Options
SharePoint Object Model - http://msdn.microsoft.com/en-us/library/ms441339.aspx
SharePoint Web Services - http://msdn.microsoft.com/en-us/library/ms479390.aspx
specifically the Lists web service
The web services is how Excel/Access communicate with SharePoint to integrate with its lists.
In fact a bit of Google foo gives these two results :-
Connecting SQL Reporting Services to a SharePoint List
Accessing SharePoint List Items with SQL Server 2005 Reporting Services
The 2 minute answer is to use Data Synchronisation Studio from Simego ( http://www.simego.com ) just point it at your List and database and it will sync all the changes.
There is an ADO.NET adapter for MOSS 2007/2010 and WSS 3.0/4.0 available which goes under the name Camelot .NET Connector for Microsoft SharePoint. It enables you to query lists in SharePoint through standard SQL language, using SharePoint as a data layer.
Besides from the connector, there will be a large number of open source tools and utilities available, such as webparts for exporting data to various formats (XML, MySQL, ..), Joomla plugins, synchronization services, etc.
See http://www.bendsoft.com for more details and to watch webcasts. BendSoft is currently looking for beta-testers and encourage all feedback from the community.
Example:
SELECT * FROM My Custom SharePoint List
INSERT INTO Calendar (EventDate,EndDate,Title,Location) VALUES ('2010-11-04 08:00:00','2010-11-04 10:00:00','Morning meeting with Leia','Starbucks')
DELETE FROM Corp Images WHERE Image Name = 'marketing.jpg'
I had written a full article about this with step by step screenshot procedures. It does not use any third party components only SQL BI Tools and Sharepoint. Have a look here
http://macaalay.com/2013/11/01/how-to-archive-sharepoint-list-items-to-sql-server/
As Ryan said I would also suggest using object model / web services to store data to separate SQL database. I think that the best approach is to write an event handler that will trigger on your least and copy the data user inserted/updated.
Regarding your query about "SharePoint 4", Bill Gates made some remarks at SharePoint Conference 2008. He suggests enriching SQL tables with SharePoint data, and goes on to mention several other potentially cool things. What exactly he means and whether it will help solve your problem in the future is hard to say until we start seeing betas of WSS4 / MOSS 14.
I would go with the simego software, but i dont have the money, maybe a 15 days trial is enough!
If you have MOSS installed, the Business Data Catalog can be setup from the Sharepoint Central Administration to automagically synchronize data for you. This is a very powerful product and is included with MOSS. I love it when a client has it enabled so I can take advantage of it.
But some don't and for myself, I've found that if they don't have BDC running and available, inevitably they don't give developers many rights to SQL Server so SSIS is generally out of the question (but maybe that's just me). No problem; for those I'll pull together a lightweight EXE that runs on a scheduled task that queries Lists.asmx and pushes changes to a SQL Server table. Fairly trivial stuff for a simple list where nothing is deleted. Get yourself Visual Studio 2008, CAML Builder, and prepare for a good time. The Lists.asmx results is a little funny in that a list's row's fields are each a single node with a lot of attributes, with no child nodes ... something like this off the top of my head ... just remember that when coding ...
<z:row ows_Id="1" ows_Field1="A1" ows_Field2="B1"/>
<z:row ows_Id="1" ows_Field1="A2" ows_Field2="B2"/>
Complications in code occur with copying lists where items are deleted, or where there is a parent/child relationship between SP lists. You'd think I'd have some code to send you, but I haven't bothered putting together something I could reuse.
I'm sure there's other ways of handling it, but the scheduled task EXE so far has been reliable for me for multiple apps for multiple years.
i wrote some code to achieve it, you can find it over here
extract data from moss 2007
Depending on the exact nature of the data you need to insert, it may be possible to just use the auto generated RSS feed to get the information you want, a process will need to read the rss and formulate a query.
Otherwise a consoleapp/service could use the object model to do the same thing, but with more control over field information.
I wish something like this was much easier to do. Something that didn't need SSIS and was boiled down to a console tool that reads a xml config file for source/target/map info.
http://blogs.officezealot.com/mtblog/archive/2008/06/03/importing-list-data-into-sql.aspx