Question

Scenario:

We have an internal application that ties Excel spreadsheets stored in a SharePoint doc lib with specific Opportunities in CRM. The user clicks on a button in the Opportunity and a Web page is opened that:

  1. Looks to see if a folder in the doc lib exists with the Opportunity's GUID.
  2. If not, then it creates that folder and copies an Excel file that is used as the template into it.
  3. Either way, it then opens the file in Excel.

The code to open the file is some client-side script that figures out the location of the Excel file in SharePoint, sets an href variable to that URL and does the following:

    objExcel = new ActiveXObject("Excel.Application");
    objExcel.Visible = true;
    objExcel.Workbooks.Open(href);

    if (objExcel.ActiveWorkbook.ReadOnly)
    {
        objExcel.ActiveWindow.Close(false);
        objExcel.Application.Quit();
        alert("This workbook is opened for editing by another user. Try again later.");
    }

Usually the above works just fine. Note that this is just opening the Excel file without checking it out.

Problem:

Once in a while, and for no reason I can figure out, a user will click the button and the spreadsheet will be returned to them by SharePoint as read-only (so they will get the above error message). However, often they are demonstrably the only user to have accessed the document - in fact, sometimes this will happen if they just created the document (i.e., they clicked the button, the folder didn't exist, and so it creates the folder and copies the new Excel file into it). Sometimes they were working on it earlier and then return and get the above message. Waiting for a while can help, but it doesn't seem like even SharePoint's inactivity timeout always does the trick. And here's the strangest part - while that user opening it may get it returned to them as read-only, often other users, even multiple other users, can click the button and the spreadsheet will open for them in edit mode!

Questions:

  1. What is causing this behavior? I can change the code to avoid it if I can figure out why it is happening.
  2. Is there any way through the SharePoint UI or APIs to "release" the document so that the original user can open it for editing?
  3. Is there any way through the SharePoint UI or APIs to tell who SharePoint thinks has the document open for editing (although in some cases that seems like it is going to be the user who is getting blocked).

I am stumped and would appreciate any help or suggestions.

Was it helpful?

Solution

When you open a file from SharePoint, a copy is created locally. In some cases the local copy is not cleaned up and can cause the problem you are getting.

Here is a post from someone with the same error, there are a couple of suggestions towards the end.

Licensed under: CC-BY-SA with attribution
Not affiliated with sharepoint.stackexchange
scroll top