In a previous post I wrote about creating a child content type of the BambooFileShareLibrary content type. This was to enable items created in SharePoint via the Bamboo File Share timer job to be set to the custom content type directly and make the additional fields immediately available when users view and edit items.
While following similar steps to make these same fields available when folders were created through the UI, I ran into an unusual problem. The control hierarchy of the page was being written to the output and the text rendered in the browser!
What I Did to Trigger the Problem
To get the functionality I was looking for, I created a new content type based on the Folder (0x0120) content type. I then added the site columns used in the previously mentioned child content type. When the new folder content type was added to the File Share Library, I saw output I wasn’t expecting. I tried the same content type on another document library and it worked as expected.
Recently I started at a new company doing in-house work. The environment is a bit different than that to which I’m accustomed by its large reliance on 3rd party utilities and solutions. While these are great for companies lacking in development staff, many of these solutions are overly generic and can be frustrating to users who are looking for a more integrated experience.
Enter me and my first project.
In my current environment, just as in every other environment I’ve seen, we have users who use and love their file shares. These bastions of untamed digital wilderness have been the bane of many an IT person but their existence continues. To help mitigate some of the drawbacks of these audit-free, backup-less storage areas, Bamboo created a product which synchronizes file share content with a SharePoint document library. The solution uses a timer job to occasionally crawl the share looking for files and folders that have been added/changed and comparing against the files it has in the SharePoint library to see if anything has been deleted. The library is kept in sync (though with the option of archiving deleted items to soften the blow of those occasional accidental share deletes) and each item has a status which reflects the synchronization type.
I was debugging a problem with SharePoint 2007 Site Usage reports on a client farm and I finally figured out the problem.
Out of the box, SharePoint 2007 uses Report Viewer controls to render Site Usage reports. These reports target Report Viewer version 8 assemblies which correspond with the Visual Studio 2005 report designer. In the recent past we deployed some reports which were designed in Visual Studio 2010. To support these reports, the SharePoint web.config was modified to use the Report Viewer version 10 assemblies. This worked to get the new reports to render but a few days later it was discovered the Site Usage reports were no longer working.
Cannot get the list schema column property from the SharePoint list.
Here’s an interesting problem I encountered at one of my clients: a SharePoint 2007 SP2 list which previously exported to Excel just fine was now producing the above error every time. Adding insult to injury this started happening after someone accidentally deleted a column from the list which was critical to the event receivers we created.
Having only the missing, and reconstructed, field as a guide, we found hiding the column from the view before export would allow the export to succeed. Armed with that knowledge I started searching like crazy. I found site after site telling me this happens with Date fields. The default value had been changed and to fix the error simply open the field, set the default value to something rational like 12/12/2008, save it, edit it and clear the value back out. Other sites advocated converting the Date field to Single Line of Text and then convert back.
While we have 26 date fields in this custom list, that wasn’t the column that was causing the problem. The faulting column was a lookup to another list. Finally after a few hours of searching I came across this awesome post. Specifically:
7. Lookup column points to a calculated field. Changed the lookup column to not point to calculated field but to a Single Line of Text field and the problem went away.