I have a SharePoint 2010 site with a document library for storing Excel files. If someone is editing an Excel file (using stand-alone Excel, not Excel services), everyone else will be forced to open the file read-only until the first person is done editing. Is there a way around this? What I want is to allow two or more people to be able to edit the file at the same time. Also, I don't want people to overwrite each other. Instead, I'd like SharePoint to merge their changes. Is this possible in SharePoint 2010?
No, sadly:
The Excel 2010 client application does not support co-authoring workbooks in SharePoint Server 2010. However, the Excel client application does support non-real-time co-authoring workbooks stored locally or on network (UNC) paths by using the Shared Workbook feature. Co-authoring workbooks in SharePoint is supported by using the Microsoft Excel Web App, included with Office Web Apps
From Co-authoring overview (SharePoint Server 2010)
...and not for SharePoint 2013 either. Though it works for pretty much all other Office documents. Go figure.
The new version of SharePoint and Office (SharePoint 2010 and Office 2010) respectively are supposed to allow for this. This also includes the web based versions. I have seen Word and Excel in action do this, not sure about other client applications.
I am not sure about the specific implementation features you are asking about in terms of security though. Sorry.,=
Here is a discussion
http://blogs.msdn.com/b/sharepoint/archive/2009/10/19/sharepoint-2010.aspx
Yes you can. I've used it with Word and PowerPoint.
You will need Office 2010 client apps and SharePoint 2010 foundation at least.
You must also allow editing without checking out on the document library.
It's quite cool, you can mark regions as 'locked' so no-one can change them and you can see what other people have changed every time you save your changes to the server. You also get to see who's working on the document from the Office app. The merging happens on SharePoint 2010.
Unfortunately, the file must be locked for updates unless you're using Office 2010 and SharePoint 2010 together. This means that only one user per time can edit a file. The locking and version tracking capabilities of SharePoint are excellent, and this makes it a great tool for the type of collaboration you're talking about, but you would have to split documents into multiple files in order to extend the amount that could be edited at a time. For instance, we sometimes unmerge documents into technical, requirements, and financials sections so that the 3 experts required for the review can work concurrently. We then merge when everyone is finished.
yes if it is SharePoint 2010 and above by using the Office feature co-authoring
Related
I'm a contractor currently working with the DOD. I work primarily with VBA and Microsoft Office (2013) to produce "Desktop Tools" because this is the level of scope in the culture here. Rarely are the clients accessing their products from a fully integrated system that connects all of their data. One reason for this are the many disparate systems that require username and password to get and collect data. So office products like MS Access, Excel and PowerPoint are the meat and potatoes of their reporting and dashboards. There has been a second life to a career using only VBA which I thought was long gone. My facility uses SharePoint 2010 and often want to see their products, like a "Desktop Access database with user security implemented" - on SharePoint. We often turn to PowerPoint to meet that need, but it is not as robust and requires a lot of manual intervention, and since many of the front end interfaces that I have built have complex form validation as well as comprehensive report views it seems to leave a lot to be considered.
I've only worked with Visual Studio between 2005 - 2009 and I know a lot has changed. I know SharePoint has also evolved extensively.
I have also heard about InfoPath, but read that I need Visual Studio if I want true control especially with data input. I have also considered the Web App component in MS Access but have many security limitations on that side that I have never considered going through with them. What are my options with SharePoint 2010 and Desktop MS Access that have all the bells and whistles available to me in VBA if I don't have access to Visual Studio or anything else besides VBA?
You have two options:
1) You can create a database with Microsoft Access and publish it to Microsoft SharePoint 2010 using the Access Services
2) You can create Sharepoint Lists and link them in Microsoft Access and work with them like tables and use VBA inside Microsoft Access
I'm trying to do a 2-way sync with an excel spreadsheet and a list on my sharepoint 2013 online public site. Research has told me that the best approach, without using 3rd party solutions, would be to use Access 2013, and to first sync the excel spreadsheet to the access database (I've done this). Next would be to sync the Access database with a sharepoint list. When I try to do this, it publishes the table as a list, but if any changes are made to the excel spreadsheet, it's not updated on the sharepoint list. Is there a specific way this needs to be done? I wasn't able to find any good documentation on this, especially for 2013 versions.
Thanks for any help!
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.
Is there a way to publish Infopath form manually? I have an infopath form that I created for sharepoint on a computer. Now, I want to move that xsn file to another dev computer where sharepoint is installed but no infopath. So, I cant use the infopath publish options. Is there a way to MANUALLY PUBLISH?
What I have tried so far is to open the xsn file and read the xsf file. That did not work.
Can someone please help me out?
Thanks,
Moving my comment to answer.
First, I did not understand what "MANUALLY" did mean... but forgot to ask.
My personal belief (from never ever sufficient experience) is that it is impossible to manually substitute the publishing (which is being done from Infopath Designer).
And the latter is proprietary undocumented about full details procedure dependent on sharepoint internals (with the latter also being proprietary and closed information).
Might be somebody else has another opinion.
Well, you can try... and report here back.
Update:
There are development suites (IDE, frameworks, extensions) where you can develop all from the scratch or use open source libraries, extensions (like .NET, MS SQL Server Business Intelligence) and the approaches where you should follow what is precompiled and closed for meddling like Sharepoint and Infopath.
There are pro and contra in both.
In any case one should analyze and balance business requirements.
Anyway, I was a little puzzled by situation when you do not have Infopath installed on client machine.
In this case, you can use Infopath forms only through Infopath Forms Services of Sharepoint Server which is enterprise and rather expensive feature.
If you (or your client have it), then Infopath (which is part of Microsoft Office suite) is usually already bundled into all Microsoft plans or packages having enterprise Sharepoint server.
There is also Office 365 (Sharepoint Online) 30-day free trials with all bundled.
Here is comparison of plans and prices.
When mine expired, I was getting warnings and proposals to buy but really continued to have access for more 4 months before my access was really cut.
It is a marketing bluff that Infopath is easy. It is easy to start by clicking a few buttons and generate something ready but this easiness pays off dearly if you will be required to do something more flexible, customizable and/or not reqadily provided OOTB (very frequently used term in Sharepoint and Infopath, Out-Of-The_Box) in Sharepoint and IP when it happens that it is more difficult, more time consuming and more involved then using development from scratch approaches
I am a .Net developer and I need to get started with SharePoint 2010 and InfoPath 2010 for a new project.
I believe I don't want too much SharePoint just the basic configuration and how to host an InfoPath form there. For InfoPath I need to know how to design forms and program it using VS2010.
I appreciate if you can provide me with some links/books to get started with SharePoint and InfoPath (with more emphasis on InfoPath development).
Edit
I really need some personalized advice instead of an entire website to surf. I will be totally lost like this.
As John alluded to - the path to learning really depends on your project needs.
My recommendation would be to learn InfoPath first. You don't need SharePoint and you don't even need Visual Studio to utilize the majority of InfoPath. You might be able to accomplish your goals right there without even delving into anything else.
If that is not enough start looking at the other things. You will need advanced programming (Visual Studio) if you are trying to customize the form experience for the user, adding functionality that is not available directly in InfoPath. Start looking down this path if you run into roadblocks with how you want your InfoPath form to work.
You will need SharePoint if you need a delivery mechanism, forms storage, tracking for the users. Start looking down this path if the forms start being complicated to manage on a file share (or if you need extra functionality like change tracking etc).
In general - start with Infopath and progress to the other things based on your needs. Programming is for the form (singular) experience, SharePoint is for the forms (plural) experience. Note also that they are not mutually exclusive - usually you end up needing both.