Basically all I want to do is to get the total storage space of subsites, document libraries and lists within a site collection. There does not seem to be a possible way to do it besides:
using site.StorageManagementInformation which is currently Obsolete
SPSite.UsageInfo this can only work for site collection:
SPSite.UsageInfo usageInfo = spSite.Usage;
long storageUsed = usageInfo.Storage;
SPWeb.GetUsageData which only gets the current day(and up to the last 31 days) usage data.
finding the database table where Site Collection Administration > Storage Metrics is querying from (which I could not find even with using a .NET Reflector for the assembly)
If anyone has any other way or idea on how to achieve this it would be very much appreciated!
my suggestion is to try opening the site you are accessing via SharePoint Designer and right click any those collections then click properties. The size of the objects should be shown there as well. :)
Related
The users have documents in Sharepoint document library. I need to be able to get the urls of these documents easy within Visio. Would I need to write something in VBA which gets the urls of these documents from Sharepoint, or is there an easier option ?
I have looked at the net use command so they can map a drive but that does not give the url.
anyone done anything like this before ?
SharePoint exposes XML interfaces that you can use to determine elements in a table or items in a library (which is a known and static location in SharePoint).
What you can use and how you access it will depend on your version of SharePoint and how it is configured on your network. However, there are plenty of examples on the internet that you can search in your favourite search engine (Alta Vista anyone?) which will get you started with some code. I expect you will have some specific questions once you start coding.
It has been a while since I did this.
This is going to be vague, hopefully not annoyingly so. I know very little about SharePoint, but I'm asking for someone who's more knowledgable but is under lots of crippling pressure. Unfortunately I'm going to be held responsible for the project (it's due before Christmas!!), so I need to see what I can figure out on my own to help out. Please allow my desperation and helplessness to excuse any problems with this question.
We've created an InfoPath form that generates xml files that will be uploaded to SharePoint. The data from these files will be aggregated and used to generate reports. The biggest issue is that the users will be spread out over three locations, and the info generated from each location needs to be firewalled from the others. But we need the xml files from all three locations to go to the same place in order to make the aggregation feasible with minimal manual work.
I've read something about SharePoint groups (http://technet.microsoft.com/en-us/library/cc262778%28v=office.14%29.aspx) and figured that might be the way of doing it, so long as 1) the xml documents could all go to the same library/repository and 2) that shared repository would only show each group their own documents. For at least two users we also need a master view that shows all of the documents regardless of the group that created them.
That's the main question. Ultimately we'll also need a similar way of storing the generated reports (tables and charts) to the creators of the xml files AND a set of users at each location who won't be able to view or create those xml files. But first things first, I guess.
Is this possible and feasible? Any hints/links that could get us started down this path?
I think in your case the best option is to create a folder for each group, and set permissions on them to allow just the specific group of users to access that folder. The same with a separate library for reports. Then, you'd just setup a list view that flattens the folder hierarchy to view all items at once.
You could also set per-document permission programmatically in an event receiver, however, there's a pretty low limit (search for ACL) on the number of unique access control lists per library (it's 50.000 actually). So depending on the number of XMLs you are going to manage you may reach this limit.
I am working on a VSTO-Excel-Addin (VB.NET) that we are about to sell to different companies.
The addin will (hopefully) be used by a couple of users of each customer. We are using ClickOnce for a web-based deployment.
The addin provides some default-settings - that is no problem with the app.config. User-specific Settings are also working fine with ClickOnce.
However what makes quite some headache is how to store settings per customer. Database-connectionstrings for example cannot be stored on the application-level but it would also be painfull for all users to change the Connection-string manually. What I would imagine is another layer (per Company) where this sort of Setting can be stored.
One alternative would be to create one VSTO-Project per customer but this would bring a lot of disadvantages since we are updating the addin quite regularly.
I would be happy about any ideas!
Regards,
Julian
I would show Excel's built in connection properties dialog and let each client configure this themselves.
You really shouldn't be distributing connection strings for all your clients as part of a shared package. It'll be a maintenance nightmare.
http://office.microsoft.com/en-nz/excel-help/connection-properties-HA010175443.aspx
What about storing the settings as custom properties in Book.xltx and copy it to
C:\Users\username\AppData\Roaming\Microsoft\Excel\XLSTART
This is how you can programatically read and create Custom Properties in Excel.
When a new workbook is created then all the properties from Book.xltx will be available for New Workbook as well. But this solution may not work if the existing workbooks are opened so yo might have to explicitly add these properties when any existing workbooks are opened using the above solution.
Ok, I think I understand the problem. :)
How about storing all the settings in an offsite database that you maintain and using a webservice to allow the settings to be read and set and giving each client a unique license number that would allow them to access this webservice.
That way the individual users would only need a license number to set it up.
We have an in-house app that uses the http://schemas.microsoft.com/exchange/permanenturl property to identify calendar appointments in 2003. Now we're getting ready to migrate to 2010, and our understanding is that the permanent urls are formed differently for calendar items, and that permanenturls from 2003 can't be upgraded directly to 2010. Someone has even suggested that the new API doesn't expose the permanenturl So, I have a few questions.
First, are we right? Can the permanenturl property not be upgraded to 2010 from 2003? If it can, is there an algorithm that allows us to predict or produce the new url? We're going to need them both on hand through the transition.
Second, I know that from 2007 and up that we can create custom extended properties that we can make persistent. I'm having trouble figuring out if we can create custom extended properties in 2003 a) at all, and b) that will persist in the migration.
I'm a total noob at Exchange programming, so I'm not even sure where to start on the code. Any pointers in the right direction would be greatly appreciated!
Thanks!
After some research and experimentation, we determined that the permanenturl doesn't persist, but that the GUID for Calendar items should be fairly reliable. The GUIDs for Items in Exchange appear to include a hash of the entry point, so moving messages between folders can change their GUID. Since calendar items stay in the same folder, the GUID shouldn't change. So we're going to use that as our new index.
There was still the matter of updating the old index. We decided to take the following course:
Copy the permanentURL value to the body of the message (actually, we're hashing a few things together)
Migrate the mailbox
Find the permanentURLs in the message bodies, get the new GUID, and update our table
Use the 2010 GUIDs going forward
This was my first time working with Exchange, and I have to say that I'm a fan of EWS. It makes things so much simpler.
I'm upgrade my sp 2007 to sp 2010 and I have a form library has more then 5000 items.
Default view of form library filter items and show only 10-20 item to users.
After upgrade sp2010 All users get below error when going to form library expect site collection admins.
I think this is a permission issue but i did not find any source to solve this issue, have any idea ?
This view cannot
be displayed because it exceeds the
list view threshold (5000 items)
enforced by the administrator.
To view items, try selecting another view or creating a new view.
If you do not have sufficient
permissions to create views for this
list, ask your administrator to modify
the view so that it conforms to the
list view threshold.
You can increase the List View Threshold beyond the 5,000 default, but it is highly recommended that you don't, as it has performance implications. The recommended fix is to add an index to the field or fields used in the query (usually the ID field for a list or the Title field for a library).
When there is an index, that is used to retrieve the item(s); when there is no index the whole list is opened for a scan (and therefore hits the threshold). You create the index on the List (or Library) settings page.
This article is a good overview: http://office.microsoft.com/en-us/sharepoint-foundation-help/manage-lists-and-libraries-with-many-items-HA010377496.aspx
The setting for the list throttle
Open the SharePoint Central
Administration,
go to Application
Management --> Manage Web
Applications
Click to select the web application that hosts your list (eg. SharePoint - 80)
At the Ribbon, select the General Settings and select Resource Throttling
Then, you can see the 5000 List View Threshold limit and you can edit the value you want.
Click OK to save it.
For addtional reading:
http://blogs.msdn.com/b/dinaayoub/archive/2010/04/22/sharepoint-2010-how-to-change-the-list-view-threshold.aspx
I had the same problem.please do the following it may help you:
By Default List View Threshold set at only 5,000 items this is because of Sharepoint server performance.
To Change the LVT:
Click SharePoint Central Administration,
Go to Application Management
Manage Web Applications
Select your application
Click General Settings at the ribbon
Select Resource Throttling
List View Threshold limit --> change the value to your need.
Also change the List View Threshold for Auditors and Administrators.if you are a administrator.
Click OK to save it.
SharePoint lists V: Techniques for managing large lists :
Tutorial By Microsoft
Level: Advanced
Length: 40 - 50 minutes
When a SharePoint list gets large, you might see warnings such as, “This list exceeds the list view threshold,” or “Displaying the newest results below.” Find out why these warnings occur, and learn ways to configure your large list so that it still provides useful information.
After completing this course you will be able to:
Learn what the List View Threshold is, and understand its benefits.
Create an index so that you can see more information in a view.
Create folders to better organize your large list.
Use Datasheet view for fast filtering and sorting of a large list.
Learn what the Daily Time Window for Large Queries is.
Use Key Filters for fast filtering within Standard view.
Sync a large list to SharePoint Workspace.
Export a large list to Excel. Link a large list in Access.