Unable to remove a field from a SharePoint list via UI

Hi,

In some cases (such as the "Page Content" field found under the Page Layout columns) it is not possible to delete a field from your list once you have added it. This is because by default some fields have their property set to Sealed="TRUE". Thus, you will not be able to delete the field via the UI, forcing you to use a coding solution. This can be achieved via the following PowerShell script:

Clear-Host
$web = Get-SPWeb http://yourweburl
$list = $web.Lists["YourListName"]
$field = $list.Fields["Page Content"]
$field.AllowDeletion = $true
$field.Sealed = $false
$list.Update()
$field.Delete()
$list.Update()
$web.Dispose()

SQL snippet which shows the progression of a database shrinkage operation

SELECT
    Percent_Complete [Completed],
    Start_time [Start Time],
    Status,
    Command,
    ((estimated_completion_time/60000)) [ETA (Min)],
    ((cpu_time/60000)) [CPU Time (MIN)],
    ((total_elapsed_time/60000)) [Total Elapsed Time (MIN)]
 FROM
    sys.dm_exec_requests 
WHERE
    command = 'DbccFilesCompact'

Full Postback Problem With AJAX in SharePoint 2013 Visual WebPart

Hi,

For months I have been battling a postback problem occurring in a visual webpart. I have a bunch of controls (dropdowns, textboxes) which are selected by the user to specify search criteria. If the user then hits the search button, a grid will be refreshed based on the selected parameters. The controls are AJAXified via RadAjaxManager, so that the calls are made asynchronous, preventing unnecessary full page postbacks. Just to go on a sidetrack here: if you encounter your SharePoint webpart doing a first full postback and then functioning fine with the controls AJAXified, you might wanna check how you set things up. The way to go is by dynamically adding an instance of RadAjaxManager and the AjaxSettings to the webpart (NOT the WebPartUserControl!). You can find more information on how to do that right here: http://www.telerik.com/forums/telerik-ajax-issue-with-sharepoint-2010. If you are still struggling, feel free to contact me and I'll try to help you out.

Ok. This seemed to work fine until I would leave the page idle for about two minutes. If the user would then trigger any asynchronous callback, the page would cause a full postback, consequently discarding all search parameters specified. The weird thing is that in IE this happened intermittently, maybe just once in every 500 requests. For Chrome/FireFox it would always happen after about 120 seconds.

I have been digging into the Distributed Cache service and doing all sorts of funky tweaking such as changing the Logon and ViewState cache request timeouts but it did not help a bit. Even after re-installing and even disabling the DCS (which tremendously sped up the page request time btw) the problem persisted.

In October, someone created a ticket with Microsoft for this issue and they stated that it had been fixed in the December CU (http://support2.microsoft.com/kb/2910943)

Now it appears that this hotfix is for foundation (thus not for Server, which we are using).

The only and only working solution for now is to disable Forms Authentication in IIS for the web application where you are using your visual webpart. I have done that just now and solved the problem. Beware that doing this might cause trouble if that web application is being used as a portal.

I hope this helps you for now. Keep an eye out for the Server CU.

-Gary