Archive for June, 2012

Client side validation of SharePoint Rich text field

Requirement: Mandatory field validation for SharePoint Rich text field in List form

Hurdles faced: Comparison of the value in the rich text field with an empty string in JavaScript returned FALSE even though there was no text in the rich text field


  1. The RTE (Rich text editor) is rendered in the following way in browser
    As can be seen in the above snapshot, the DIV where the data is stored is the second child of the parent div. This is the scenario where no data is inserted in the field
  2. First thing that we tried is to fetch the inner text of this DIV element
    As can be seen, text() returns “” i.e. empty string
  3. Now, we try to compare this with empty string in JS 
  4. As the above returned false, we decide to check the inner HTML present in that DIV
    The inner HTML returned empty paragraph tag. If you observe, there is a space between ‘<’ and ‘/p’.We now try to compare this inner HTML with the empty paragraph tag:

    Even this did not return TRUE
  5. On double clicking the value returned in inner Text and HTML, a space was found to be inserted

  6. On digging deep, this space was found to be a Unicode character inserted by SharePoint viz. ZERO WIDTH SPACE
    “%E2%80%8B” is the value returned on encoding this space using JavaScript
  7. Thus, the conclusion is that we need to compare with this ZERO WIDTH SPACE
  8. One option is to compare the text() with “%E2%80%8B”; but, this will still return FALSE when the focus is on the Rich text field.
    In order cover both scenarios, Regex helps us to replace this Unicode character viz. ZERO WIDTH SPACE with normal empty string viz. “” 
    As can be seen, the Unicode character (\u200B) is used in the Regex for comparison and replaced with empty string
  9. We can compare the replaced value with an empty string to get TRUE as return value

    This is the required SOLUTION

SharePoint Configuration Database in Suspect Mode


Unable to load my SharePoint site hosted on a VM. Page threw the error viz. ‘Cannot connect to configuration database’

Resolution (Steps taken):

  1. Observed that ‘SharePoint_Config’ DB was in Suspect mode. In SSMS, I found the Suspect status with SharePoint_Config DB
  2. On restarting SQL services, Recovery status was displayed with SharePoint_Config DB
  3. After the recovery process completed, the DB name was rendered properly in SSMS; but, page still threw the error viz. ‘Cannot connect to configuration database’
  4. After some time, Suspect status had resurfaced on viewing in SSMS. This showed that the DB was still corrupt
  5. In such scenarios, one option would have been to restore the DB with an old backup. In my case, I did not have a backup L
  6. On searching the net, I found few blogs mentioning this issue
  7. As per the blogs, the SharePoint DB gets corrupt occasionally when the VM restarts untowardly
  8. Script that helped me resolve the issue:
    -- Use the Master database
    Use Master
    -- Verify that database has issues
    EXEC sp_resetstatus 'SharePoint_Config'
    -- Put the database in emergency mode
    DBCC checkdb('SharePoint_Config')
    -- Set the database in single user mode
    -- Repair the database with data loss
    DBCC CheckDB ('SharePoint_Config', REPAIR_ALLOW_DATA_LOSS)
    -- Set the database in multi-user mode
    -- Verify that database is reset
    EXEC sp_resetstatus 'SharePoint_Config'
  9. PFA: SharePoint_Config_Recovery.sql, SQL script mentioned in the blogs which helped me resolve the issue
  10. Script tries to set the DB in Emergency mode and repair the data loss. This should be applicable to any DB which gets corrupt and goes into Suspect mode