SharePoint 2010 has "Author" column as a default site column. Author means a primary author of each document.
*Note: Author (InternalFieldName: _Author) and Created By (InternalFieldName: Author) is different.
Here is the screenshots in order to set author name to author column of SharePoint 2010 Document Library.
After clicking on "Grant Author(s)" button at the bottom, you wee see that all Author fields are filled up as shown below.
Here is the code I have written down:
Friday, July 20, 2012
Download all files from SharePoint Document Library
Now, we are going to see how we can download all documents(incluing sub folders) from SharePoint Library.
First of all,we have get all documents from SharePoint Library. The following code help us to get all the documents including Subfolders.
//Get the Document Library and its viewSPList list = web.Lists["Test Document"];
SPView view = list.Views["All Documents"];
//Get the Document Library and its viewSPList list = web.Lists["Test Document"];
SPView view = list.Views["All Documents"];
//Query all documents in Library including files under subfoldersSPQuery squery = new SPQuery(view);squery.ViewAttributes = "Scope=\"Recursive\"";
SPListItemCollection items = list.GetItems(squery);
Now we have to write a code for downloaing documents,
//Read all documents and write those files to Local System
foreach (SPListItem item in items)
{
byte[] binfile = item.File.OpenBinary();
FileStream fstream = new FileStream(“F:\” + item.File.Name, FileMode.Create, FileAccess.ReadWrite);
fstream.Write(binfile, 0, binfile.Length);
fstream.Close();
}
//Read all documents and write those files to Local System
foreach (SPListItem item in items)
{
byte[] binfile = item.File.OpenBinary();
FileStream fstream = new FileStream(“F:\” + item.File.Name, FileMode.Create, FileAccess.ReadWrite);
fstream.Write(binfile, 0, binfile.Length);
fstream.Close();
}
By using the above code snippets, we can download all document from SharePoint Library.
SPWeb.Lists & SPWeb.GetList
There are many posts on this topic. So why I am writing one more post? Well just to share my experience and hope others will benefit from this.
SPWeb.GetList (string strUrl) – Good
using (SPSite site = new SPSite(strSite))
{
using (SPWeb web = site.OpenWeb())
{
SPList oList = web.GetList(http://Site/list/AllItem.aspx)
}
}
In this case, first retrieves the list GUID from the url (database hit), then it loads the metadata* for that specific list.
SPWeb.Lists (“name”) – Not Good
using (SPSite site = new SPSite(strSite))
{
using (SPWeb web = site.OpenWeb())
{
SPList oList = web.Lists ["MyList"]
}
}
In this case, it loads the metadata* of the all lists in that specific SPWeb object. Then it does SPList.Title comparison with metadata of all the lists returned and then it returns the matching list from the SPWeb.Lists collection.
Most of the posts have recommended using SPWeb.GetList (string url) instead of SPWeb.Lists [“”] to get list instance. Logically, SPWeb.GetList seems to be more performance oriented compared to the retrieving collection of lists, because first method tries to get Guid to retrieve the list and later populates list collection and then retrieving one of the items. So I started changing all calls made to get list from SPWeb.Lists [“listName”] to SPWeb.GetList (“/lists/listName”) in SharePoint application. To my surprise code was performing 5 times slower than previous version. I had used ANTS Performance Profiler tool to profile SharePoint application.
In my opinion following are reasons which has caused application to perform badly after change.
1) SPWeb.Lists [] pulls information for all the lists in one attempt. This call may be slow, but once information is available in the memory, going through list collection is faster than database call. If SharePoint web site has 25 lists, only one call is made and data retrieved is reused for further processing.
2) SPWeb.GetList () makes separate database call for each and every list for which information needs to be pulled. So if you have 25 lists to work with, 25 calls will be made. It makes overall performance of application slow.
Our SharePoint environment has 250,000 lists. (10,000 sub sites X 25 lists). Though this environment has so many list, as list are scoped at web level, loading collection of 25 list is much faster than loading individual list on every call. Loading collection will consume more memory, compare to loading individual list, but once all the lists are loaded in the memory one by one, memory foot print will be same as loading entire list collection once.
Conclusion: For web with moderate numbers of list it is better to use SPWeb.Lists []. Do not get overwhelmed with total number of lists in the site collection. SPWeb.GetList will perform better compared to SPWeb.Lists [], if number of lists in the web are large (I don’t have idea what that number is. If you have 1000s of list in web it may be time to rethink of your design.).
Don’t follow all best practice blindly unless it’s coming
1) directly coming from Microsoft
2) applicable to your problem.
SPWeb.GetList (string strUrl) – Good
using (SPSite site = new SPSite(strSite))
{
using (SPWeb web = site.OpenWeb())
{
SPList oList = web.GetList(http://Site/list/AllItem.aspx)
}
}
In this case, first retrieves the list GUID from the url (database hit), then it loads the metadata* for that specific list.
SPWeb.Lists (“name”) – Not Good
using (SPSite site = new SPSite(strSite))
{
using (SPWeb web = site.OpenWeb())
{
SPList oList = web.Lists ["MyList"]
}
}
In this case, it loads the metadata* of the all lists in that specific SPWeb object. Then it does SPList.Title comparison with metadata of all the lists returned and then it returns the matching list from the SPWeb.Lists collection.
Most of the posts have recommended using SPWeb.GetList (string url) instead of SPWeb.Lists [“”] to get list instance. Logically, SPWeb.GetList seems to be more performance oriented compared to the retrieving collection of lists, because first method tries to get Guid to retrieve the list and later populates list collection and then retrieving one of the items. So I started changing all calls made to get list from SPWeb.Lists [“listName”] to SPWeb.GetList (“/lists/listName”) in SharePoint application. To my surprise code was performing 5 times slower than previous version. I had used ANTS Performance Profiler tool to profile SharePoint application.
In my opinion following are reasons which has caused application to perform badly after change.
1) SPWeb.Lists [] pulls information for all the lists in one attempt. This call may be slow, but once information is available in the memory, going through list collection is faster than database call. If SharePoint web site has 25 lists, only one call is made and data retrieved is reused for further processing.
2) SPWeb.GetList () makes separate database call for each and every list for which information needs to be pulled. So if you have 25 lists to work with, 25 calls will be made. It makes overall performance of application slow.
Our SharePoint environment has 250,000 lists. (10,000 sub sites X 25 lists). Though this environment has so many list, as list are scoped at web level, loading collection of 25 list is much faster than loading individual list on every call. Loading collection will consume more memory, compare to loading individual list, but once all the lists are loaded in the memory one by one, memory foot print will be same as loading entire list collection once.
Conclusion: For web with moderate numbers of list it is better to use SPWeb.Lists []. Do not get overwhelmed with total number of lists in the site collection. SPWeb.GetList will perform better compared to SPWeb.Lists [], if number of lists in the web are large (I don’t have idea what that number is. If you have 1000s of list in web it may be time to rethink of your design.).
Don’t follow all best practice blindly unless it’s coming
1) directly coming from Microsoft
2) applicable to your problem.
SharePoint Column Names: Internal name mappings for non alphabet
Whenever creating any column for list, SharePoint creates two names for it.
- External name to display in views, forms
- Internal name
Best example to understand internal name is “Created By” field which is having internal name “Author”.
You can change the display name as many times as you want, but can never change the internal name once column is created.
If you are creating field from code behind then you can assign internal name as per your choice, but when doing it thru web SharePoint gives you option to give display name, and creates internal name by itself. When internal name is defined, if you have any of the non alphabet, numeric character as part of name ,SharePoint converts them to special hex codes.
For e.g. trying to create field “Emp Name” gives internal name as “Emp_x0020_Name”
( I guess this may be seems to be part of some security settings, to avoid sql injection etc, since they are allowing characters like ‘(quote), =(equal to), “(double quote), ; (semi colon) etc. You can create column with name ‘ or ’1=1 which means lot in security)
After some trial and errors I was able to build the conversion table for future reference.
SharePoint List Internal Field Names – SharePoint 2010
I noticed today that Frode has recently added a new blog post with an updated list of internal column names for SharePoint 2010.
I linked to Frode’s original blog post for MOSS 2007 a couple of years ago so it seemed like a good idea to link to this new list as it may well be useful to some.
The list of fields along with GUID and internal name information can be found below. For more information please checkout Frodes awesome list of SharePoint Column Field IDs – for SharePoint 2010.
My original blog post can be found by following this link:
SharePoint Internal Field Names
I linked to Frode’s original blog post for MOSS 2007 a couple of years ago so it seemed like a good idea to link to this new list as it may well be useful to some.
The list of fields along with GUID and internal name information can be found below. For more information please checkout Frodes awesome list of SharePoint Column Field IDs – for SharePoint 2010.
My original blog post can be found by following this link:
SharePoint Internal Field Names
Thursday, July 19, 2012
SharePoint 2013 Preview has released on July 16, 2012 !!
SharePoint Server 2013 Preview is designed to bring people together to get work done. Whether you’re using it to manage your enterprise content, make it easy for business end users to share ideas and information, or help developers build innovative new applications, SharePoint Server 2013’s improvements in scale, security, and flexibility have you covered.
- Scalable – support for the most demanding workloads with end-user experience in mind.
- Secure – governance, information protection and control – the right people access the right information.
- Flexible – deploy quickly & easily and upgrade on your terms – online and on-premises.
Subscribe to:
Posts (Atom)