Recurring Meeting workspace error: g_InstanceID missing & Listview Webpart not finish Loading

25. September 2011 19:41 by Eric in SharePoint  //   Comments (0)

Just got a client support phone call this morning, in terms of the meeting workspace she just created earlier on. Basically, the left-hand side meeting dates got frozen up, and then her ListView web-part didn't stop loading the items from the Custom List.

Well, obviously those issues seem relating to SharePoint meeting template JavaScript errors at the first look of it. After using SharePoint Designer investigating the cause of it, I quickly found out that she created this meeting workspace by inheriting a custom master page. Therefore, rolling out the following those 2 steps can quickly fix the first issue:

  • Quickly drop the following mark-up on the top of custom MasterPage assembly registration area
    <%@ Register Tagprefix="Meetings" Namespace="Microsoft.SharePoint.Meetings" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
  • Add on the following meeting template property tag right after the asp.net starting From tag:
    <Meetings:PropertyBag runat="server"/>

After publishing the updated custom MasterPage, the meeting date links seem working right away but the ListView web-part still can't finish the item loading. After a bit poke-around, there are 2 quick solutions which fix the problem, either by clearing out the server-side caching (recycle the app pools, reset the IIS and so on), or removing this particular webpart from the page, and add it back in.

Hope this quick blog entry would benefit other SharePoint consultant/developer on the similar issue ;)

Resolve SharePoint Document Locked for Editing Issue

6. September 2011 16:16 by Eric in SharePoint, SQL Server  //   Comments (0)

This morning I got a support request from the client I'm consulting with, basically he's having a "SharePoint Document Locked for Editing" issue while working with SharePoint documents. Most of the time, it's a valid warning message, which notifies that someone else might edit the document during the same period of the time.

Some other time, it turns out that there is no current user having this document open for editing, and just couldn't help wondering how this could be possible?

Under the hood, this issue could be caused by the following scenarios:

  • 1. The Microsoft Office products cashes while you were working on that particular document
  • 2. PC crashes while the document is open
  • 3. Loss of network connection (network issue) while document is open
  • 4. And more

Well, there is a few quick fixes out there to work around this issue by removing the local copy of the file under the local user account CacheFolder. However, the major downside of this approach is to require the access to the user PC, in order to remove the cached copy from there.

Therefore, what if that particular user doesn't show up for work that day, or we couldn't get hold of the user via the phone/email?

The solution hereby is to build a small program to unlock the document/file against SharePoint Content Database. (I'm fully aware of that direct updating SharePoint Content database is not encouraged by Microsoft SharePoint Best Practice Guide), however, if you know how AllDocs table works and make sure that your query will still keep the referential integrity of the data, this approach might work perfectly for you in this case.

The type of the application itself could vary (windows form/console/web applications) based upon your speciality and strength, the magic here is the code snippet below, by which it updates the values from CheckoutExpires Column in order to drop the lock of the file.

private void UpdateItemCheckoutExpiration(SPListItem item)
        {
            SqlConnection contentDatabaseConnection = null;
            try
            {
                contentDatabaseConnection = new SqlConnection(item.Web.Site.ContentDatabase.DatabaseConnectionString);
                contentDatabaseConnection.Open();

                string updateCommandText = string.Format("UPDATE dbo.AllDocs SET CheckoutExpires = '{0:yyyy-MM-dd HH:mm:ss:fff}' WHERE Id = '{1}'",
                    DateTime.Now.ToUniversalTime(), item.UniqueId);

                SqlCommand updateCommand = new SqlCommand(updateCommandText, contentDatabaseConnection);
                SqlDataAdapter contentDataAdapter = new SqlDataAdapter();
                contentDataAdapter.UpdateCommand = updateCommand;
                contentDataAdapter.UpdateCommand.ExecuteNonQuery();
                contentDatabaseConnection.Close();
            }
            catch (Exception)
            {
                // handle exception here                
            }
            finally
            {
                if (contentDatabaseConnection != null && contentDatabaseConnection.State != ConnectionState.Closed)
                    contentDatabaseConnection.Close();
            }
        }

Once the query has been executed against the SharePoint database, the file itself will be release instantly. Therefore, by having this awesome software, we won't worry about some naughty users open the documents without checking it out and go for lunch, then there's no way force it free if you can't get hold of their PCs.

Happy SharePointing ;)