Users can’t edit document in SharePoint 2013 with Word 2013

There are so many reasons that can prevent users from editing a document. If you are experiencing the same symptoms and have the same environment as described below then you are probably having the same problem and my solution should work for you too.

Case and Environment

  • SharePoint 2013 (build 15.0.4667.1000)
  • Word 2013, 32 bit (build 15.0.4615.1000)
  • Users can open and edit documents with Word 2010 without any problem
  • Users can open documents as read only but they can’t edit documents in Word 2013. Word 2013 hangs and the process must be killed.
  • IMPORTANT!: The document library or the content type has a choice field with only number choices (relatively big numbers)


After some time lost in troubleshooting (checking form another PC, inspecting the document content, checking permissions, inspecting the traffic with Fiddler,…) I didn’t find anything. Then I started removing columns from the content type one by one and testing the result. As soon as I removed one of the choice columns the problem was gone. Obviously Word 2013 is having troubles with SharePoint choice fields. That choice field had 15 choices and all were big numbers (2000,2001,…,2014). I added the choice field back and started to experiment with different range of consecutive numbers and got the following results:

Choice Values Edit in Word 2013
49,50,…,60 OK
49,50,…,62 OK
49,50,…,64 Failed
157,158,…,164 OK
154,155,…,164 Failed
1162,1163,1164 OK
1560,1561,1562,1563,1164 Failed

From the results we see that Word 2013 has more problems with bigger numbers, it can handle 14 choices with smaller numbers (sequence 49,50,..,62) but it can only handle 3 values with bigger numbers (sequence 1162,1163,1164).
The results presented above probably depend on the available resources for Word 2013, so on another more powerful PC it would probably be able to handle more choice values.
I can’t be sure what Word 2013 is trying to do when it has only number choices but we can add a text choice so Word 2013 treats them all as text. As soon as a text choice is added to the field Word 2013 works fine.
In my case I fixed it by adding a text choice “NA” so now the choice field has the following choices “NA”,”2000″,”2001″,…,”2014″.


Since Word 2010 is working fine with the same SharePoint choice field its clear that this is a Word 2013 issue, a bug we hope will be fixed with future updates.
As a workaround the problem can be fixed by adding at least one text choice value for the choice field which has only number choices.


“This file cannot be saved because some properties are missing or invalid”


This file cannot be saved because some properties are missing or invalid.
Use the Document Information Panel to provide the correct property values. Errors for required properties are marked with a red asterisk, and errors for invalid properties are marked with a red dashed border.

Only specific pattern allowed. Only data in the following pattern is allowed: ‘.*\S.*’


There is a document library in SharePoint 2010 site. Users are using Office 2010 32-bit.Saving an open document from client computers doesn’t work for all the client PCs. On some PCs saving the document fails and this error is shown: “This file cannot be saved because some properties are missing or invalid. Use the Document Information Panel to provide the correct property values. Errors for required properties are marked with a red asterisk, and errors for invalid properties are marked with a red dashed border”.
In the Document Information Panel there are no properties marked with red and everything looks fine.


There are two cases I discovered that experience this problem and both are caused from the same bug in Office.

Case 1:

Labels are enabled for the content type in the document library and the label specified contains line breaks, for example {Field1}\n{Field2}.
The error occurs even without inserting the label in the document’s content. After removing the line breaks from the label the documents can be saved.

Case 2:

There were some hidden columns in the document library’s content type. I made them Optional and opened a document from a PC that is having the problem. In the Document Information Panel there was one property marked with a red dashed border.

This file cannot be saved because some properties are missing or invalid.

Right clicking and selecting “Full error description…” popped-up the following message: “Only specific pattern allowed. Only data in the following pattern is allowed: ‘.*\S.*’”.

“Only specific pattern allowed.

It turns out that the validation is not allowing line breaks in the property. After removing the line breaks I was able to save the document.

The question now is why the problem was present only on some of the PCs. Checking the Office build version discovered that the problem was present only on client PCs with Office 2010 14.0.7106.5003. Client PCs with Office 2010 without service packs (14.0.476.1000) are not having this problem. This is a bug introduced with Office 2010 updates. Microsoft is aware of this bug and they are working on it and will be fixed with the next Office 2010 updates. It’s been few months since then (October 2013) and the issue is still present. Hopefully they will release the hotfix soon.


(Bug fixed. Check UPDATE 24/03/2014 at the end of this post.)

Because this is a bug in Office 2010, as a temporary “solution” I uninstalled Office 2010 14.0.7106.5003 and installed a clean Office 2010 14.0.476.1000 without service packs. I’ll stick with 14.0.476.1000 until Microsoft fixes this bug. Hopefully it won’t take too long until they release the hotfix.

UPDATE 22/01/2014:
To find out which update is the problem I performed the following:

-Installed clean Office 2010 (32 bit) 14.0.476.100 – The issue is not present

-Then Installed Service Pack 2 14.0.7015.1000 –The issue is not present

-Then installed the updates after SP2 one by one until the problem started.

Discovered that KB2826026 (08/10/2013) is the update that has introduced this bug.

-To make sure that this is the only problematic update I uninstalled KB2826026 and installed the other latest updates (except KB2826026) and the issue is not present.

Microsoft hasn’t released the fix for this bug yet. Uninstalling KB2826026 solves the problem temporarily until the hotfix is released.

UPDATE 25/02/2014:
“The KB2826026 has been replaced by the KB2837583 (released 11/02/2014) but Microsoft did not remove the bug brought by the first KB. So you have to uninstall the KB2837583 otherwise you will have this bug again …” – visitor’s comment (Nicolas).

In my case uninstalling KB2826026 (now KB2837583) fixed the problem. If in your case that doesn’t solve the problem then try by uninstalling other updates released after September 2013. Check the comments below.

UPDATE 12/03/2014:

KB2837583 (released 11/02/2014) is now replaced with KB2878225(release 11/03/2014) but the bug is still not fixed. So this update (KB2878225) must be uninstalled too.

UPDATE 24/03/2014:

Good news! The bug is fixed with hotfix KB2878228. You have to download and install it manually because its not included with the automatic updates.

Strings truncated to 256 characters when importing Excel sheet to SQL Server


Value of some Excel cells which contain long strings are truncated to 256 characters when importing an Excel sheet to SQL Server.


There is an Excel sheet which should be imported to SQL table using SQL Server import data wizard. In the wizard the data types mapping is set to nvarchar(max) so the strings longer than 256 chars are imported without being truncated. Import is executed and finished without errors. When checking the resulting table all long string are truncated to 256 characters even though the field type is nvarchar(max).


SQL checks the first 8 rows to make assumption for the data types. If there are no strings longer than 256 characters in a particular column in the first 8 rows SQL will consider it as nvarchar(255) and will truncate all the cells of that column to 256 character. Even if you change the mapping type in the import wizard to be nvarchar(max) it will ignore it and won’t fix the problem. The worst thing is that the import is finished “successfully” without any error or warning about the truncated strings.


There are two ways to fix this:

  1. If there are cells with text longer than 256 characters then make sure you have such a row in the first 8 rows. For example add a temporary row in Excel before importing in the first 8 rows and add strings longer than 256 characters to let SQL know that that column should be treated as nvarchar(max).
  2. Another way is to change a registry key (HKLM\Software\Microsoft\Jet\4.0\Engines\Excel\TypeGuessRows) and increas the default number of 8 column that SQL uses to guess the content of the rows to a bigger number so it will includes the string longer then 256 chars in its evaluation.
    Check this link for more details about changing this registry key PRB: Transfer of Data from Jet 4.0LEDB Source Fails with Buffer Overflow Error
%d bloggers like this: