This post is a contribution from Aaron Miao, an engineer with the SharePoint Developer Support team.
For various reasons, people want to change the file extension of an existing item in a document library. For example, with SharePoint 2007, files with JSON extension in document library can be opened without problems. However, once you upgrade to SharePoint 2010, you cannot open the file anymore. You’ll get an error similar to what’s shown below.
An error occurred during the processing of /Shared Documents/test.json.
The page must have a <%@ webservice class=”MyNamespace.MyClass” … %> directive.
In order to be able to see the JSON file content with SharePoint UI, one option is to change the file extension from JSON to TXT. But you cannot change the name or display name of the file. This can be accomplished by two methods as shown in the below samples that uses PowerShell. And of course, you can do the same with SharePoint server OM.
Use SPFile.MoveTo
$site = Get-SPSite "http://yoursite"
$web = $site.RootWeb
$list = $web.Lists["Shared Documents"]
$item = $list.GetItemById(0)
$file = $item.File
$file.MoveTo($item.ParentList.RootFolder.Url + "/” + ”test.txt")
$file.Update()
Use SPFile.CopyTo
$caml = '
<Where>
<Eq>
<FieldRef Name="File_x0020_Type" />
<Value Type="Text">json</Value>
</Eq>
</Where>
'
$query = new-object Microsoft.SharePoint.SPQuery
$query.Query = $caml
$items = $list.GetItems($query)
foreach($item in $items)
{
$url = $file.ServerRelativeUrl
$newurl = $url.replace(".json", ".txt")
$file.CopyTo($newurl)
}
Hope this was helpful.
This post is a contribution from Balaji Sadasivan, an engineer with the SharePoint Developer Support team.
As most of you are already aware SharePoint stores both the person/group field and the metadata fields as lookup values internally.
SharePoint dynamically creates a stored procedure to store the lookup values in SQL. The stored procedure accepts a number of parameters from SharePoint to perform these operations. And when the number of parameters exceeds 2100, it will throw an error. This limitation of SQL is documented in this TechNet article Maximum Capacity Specifications for SQL Server.
So now the question arises as to how many lookup values can we add before we hit this limitation?
Here’s what my testing so far shows. By no means is this an authoritative or an official data.
Now we need to note that the SQL limitation is for a list item and not for individual fields. This means that if you have 2 metadata columns that total values present in both the columns combined cannot exceed approximately 250 values. This becomes exceedingly complicated when you have multiple types of lookups grouped together and hence you must exercise caution considering these limitations.