locked
Documents becoming "locked for editing" by self, when no other edits are happening

    Question

  • On our SharePoint 2007 SP1 farm, intermittently, when a user opens a Microsoft Office document (usually Excel) for editing by single-clicking its name in IE, the following error dialog mysteriously occurs when Office opens:

    File in Use
    myfile.xlsm is locked for editing
    by 'domainname\yourname'
    Open 'Read-Only' or click 'Notify' to open read-only and receive notification
    when the document is no longer in use.

    The problem is, nobody else is editing this document, and the identified user ('domainname\yourname') is the name of the current user (the person opening the document right now)!

    This is not "user error", e.g., the same user editing the file from two different computers, or the file being checked out. This is a real, intermittent problem. If the same user opens the same file again 1 minute later, the problem might be gone, even though nothing changed.

    It's almost as if some kind of intermittent race condition is happening, where the document gets locked too early...?

    We are completely stumped. Any ideas?

    Other details:
    - SharePoint servers (1 front-end, 1 query, 1 indexing) are all Windows 2003 Server
    - SQL Server 2008 on database server
    - Clients are mostly Windows XP
    - Our versioning model is:
    --- Content approval: not required
    --- Document Version History: Create major versions
    --- Require Check Out: No

    Tuesday, June 02, 2009 2:15 PM

Answers

  • Hi,

     

    This is because when a document is opened by a client program, Windows SharePoint Services puts a write lock on the document on the server. The write lock times out after 10 minutes. Users cannot modify the document during the time when the document is locked. To work around this behavior, wait 10 minutes before opening the document again.

     

    I think this KB article can help you: http://support.microsoft.com/kb/899709

     

    Let me know the result.


    Xue-Mei Chang
    Thursday, June 04, 2009 3:27 AM
    Moderator
  • I agree: Office Web Apps is not a viable solution to this problem. The feature set available in Office Web Apps can not compare to the features available in the client app. Due to the limited feature set, Office Web Apps rarely works as an enterprise-wide replacement for the client.

    I feel for you guys. It was a huge headache for me when I was getting this problem, too. Watching the network traffic with Fiddler is what led us to our load balancer as the culprit. The networked request from Office to SharePoint to lock/unlock the file was failing. Even though you have a single WFE, I would still recommend inspecting the network traffic. There may be something else in your network (a switch, router, hub, etc.) that is causing problems with a request somewhere along the line. If nothing else, you mayat least see that the traffic is all clear and can scratch my solution off your list.

       ---PaulE---

    PS--We've had no troubles with our SharePoint Server 2010 farm which was deployed after our solution was found.
    • Proposed as answer by AseemN Monday, May 16, 2011 7:55 PM
    • Marked as answer by Mike Walsh FIN Tuesday, May 24, 2011 10:05 AM
    Thursday, March 31, 2011 7:25 PM

All replies

  • Another clue:

    Many times when this happens to users, they have access the file using WebDAV. They place a shortcut on their desktop to:

    \\nameofserver\folder1\folder2\folder3\myfile.xls

    double-click it, and the problem occurs immediately.

    But the problem is still intermittent. It doesn't happen every time, and it goes away by itself (sometimes just seconds later).
    Tuesday, June 02, 2009 2:36 PM
  • Hi,

     

    This is because when a document is opened by a client program, Windows SharePoint Services puts a write lock on the document on the server. The write lock times out after 10 minutes. Users cannot modify the document during the time when the document is locked. To work around this behavior, wait 10 minutes before opening the document again.

     

    I think this KB article can help you: http://support.microsoft.com/kb/899709

     

    Let me know the result.


    Xue-Mei Chang
    Thursday, June 04, 2009 3:27 AM
    Moderator
  • Thank you Xue-Mei: Let me see if I understand this correctly.

    Just now, I opened a Word document, made a small edit, and saved.  I did it 5 more times in a row, quickly.  Nothing stopped me: I did not see a "locked for editing" message.  I assume the write lock is being removed when Word exits... correct?

    Based on the KB article, it sounds like this 10-minute write lock applies only if the editing program has terminated abnormally, leaving the write lock in place.  This I understand.

    However, my clients are not saying anything about Word or Excel crashing. They're just opening a SharePoint file and getting the "locked by yourself" error.  I have not seen any evidence that our users are experiencing a crash beforehand.

    Perhaps even when the application exits normally, sometimes the write lock is left around, i.e., a Microsoft bug.

    That being said... when my users encounter the problem, sometimes a few seconds later (not 10 minutes), the problem goes away.  So I'm not completely convinced this is the cause... but it's the likeliest story I've heard so far.

    Any other thoughts?
    Thursday, June 04, 2009 4:05 AM
  • Hi,

    You Can try this:

    When User clicks Edit in Microsoft Word  in a SharePoint document library
    Word launches and tell SharePoint that a document is opend for editing (locked for other users)
    A copy of the document is downloaded and stored in a hidden system folder on your local computer. By default, this is located  in:

    C:\Documents and Settings\UserName\Local Settings\Temporary Internet Files\Content.MSO

    Normally, when you close the Office product, the file is removed from the Content.MSO folder
    If someone occurs that prevents the document from cleaning itself up(such as Network connectivity Lost etc.,) , it is possible that Office will continue to tell you the file is locked for editing.

    The solution to the problem is to simply delete all the files out of the Content.MSO folder and attempt to open the document again from SharePoint.Make Sure U take backup before deleting :)

    Let me know the results....

    Thanks,
    Anu

    Friday, June 26, 2009 5:32 AM
  • Thanks for the suggestion on how to clean up if the problem occurs... but I am looking for a way to stop the problem from occurring.  Documents that are suddenly "locked by yourself" are a real turn-off to our users, since this problem never happens on a share drive.
    Wednesday, July 22, 2009 6:44 PM
  • any progress with this issue other than waiting for 10 mins or deleting the contents of the mso folder ? 
    Derek
    Monday, November 23, 2009 4:27 PM
  • No. This seems to be a basic, unsolvable shortcoming of SharePoint.
    Monday, November 23, 2009 5:30 PM
  • Has anyone fixed this? The more people in our organization start using SharePoint the more often this is happening and the more I am getting yelled at by users.

    Deleting the content.mso is unnacceptable since usually they have saved a more recent copy and it is in the drafts folder. Waiting 10 minutes is not acceptable either. I don't know what could be happening or if connectivity is actually dropped because I never notice losing connectivity to anything at any other time nor do your sysadms see anything.

    I know that the interal lock is the problem since when I use the sharepoint administrator software to go look up the document i can see the internal lock. I was wondering if I wrote something to use the object model to remove this lock would it work? Then I can instruct the site administrator how to use it.
    Edit: that won't help much now that I think of it, they'll still have to upload the latest version again.

    I am telling people to try this solution as a workaround, but haven't heard from anyone if it works: http://blogs.officezealot.com/legault/archive/2006/03/31/9546.aspx the business side is not happy with giving users a complicated workaround when most of them are not very computer savvy.

    The other idea I am trying is have them change the "Save" setting under Word/Excel Options from local drafts to web site. Maybe it will keep saving there and that will cause it to stay in communciation with the server.
    Thursday, February 11, 2010 9:06 PM
  • To the best of my knowledge, this timeout is a documented feature. I haven't heard anything about plans to fix it.
    Monday, February 22, 2010 5:15 PM
  • Have you tried changing you settings in Word/Excel/Powerpoint for the save location for checked out files?  In Word, you go to Word Options, Save, Offline editing options for document management. Check the option for web server.  This eliminates the save to the drafts folder on your computer, which we've found tends to cause the most issues.
    Thursday, February 25, 2010 6:39 PM
  • In our case, we've configured our document libraries not to require checkouts, so I believe that means there are no files being saved in the Drafts folder.
    Friday, February 26, 2010 2:34 AM
  • We are finding that the users having this problem are on Windows 7 or Windows Server 2008. The latest is that if these users don't go through the load balancer (i.e. they put a HOSTS entry that points the domain name for our SharePoint site to a single WFE), things work fine. We've captured a few Fiddler sessions whereby the UNLOCK request fails to get a response when going through the load balancer, but I've also seen cases where LOCK and OPTIONS fail (OPTIONS typically fails as "unauthorized"), as well.

    I don't have anything to suggest as a solution yet, but thought others might want to know that we've been able to resolve some problems by eliminating the load balancer from the loop. I'm working with our Network Admin to see if he knows any reason this may be (who knows; maybe he's blocked those types of http requests for some crazy reason!).

    The investigation continues!

    Wednesday, July 21, 2010 7:37 PM
  • we have the prob with Windows 2003 servers and XP PC's.

    The SP is also loadbalanced, but when I try to use the server directly, and so bypassing the loadbalancer, I still have the same problem...

     

    Friday, August 06, 2010 11:36 AM
  • Strange thing is on my end, that this only occurs in lists where users have a "Contribute" permission set.

    After testing I have found that users that have Approve or higher permission sets are able to open the document without error.  The only problem with this is that it defeats the logic of some custom workflows...

    Very curious....

    Friday, August 06, 2010 3:04 PM
  • Xue-Mei Chang's answer is technically correct but incomplete and impractical. The 10-minute write lock exists, but it also happens without warning to individual users, locking themselves out in the middle of an editing session:

    1. User Smith edits a document.
    2. User Smith keeps the document open and continues editing.
    3. In the middle of the session, the SharePoint server "forgets" that Smith has the document locked. It releases the lock.
    4. User Jones opens and edits the same document.
    5. User Smith, who still has the document open, tries to save and is told Jones has it locked, even though Smith originally locked it and had it open the whole time.
    6. User Smith gets angry and stops trusting SharePoint.

    The only answer I get from Microsoft on this, repeatedly, is, "There's a 10-minute write lock."  Microsoft never says, "Step 3 is a bug," even though it clearly violates version control and locking, in a manner I have never seen in any other system.

    I am the original poster of this thread. Our solution, unfortunately, has been to get rid of SharePoint.

    Friday, August 06, 2010 4:35 PM
  • So, after discovering that our locking issue did not occur when we bypassed the load balancer, we talked with our network admin in charge of the F5 device. We had been using cookie-based load balancing. In this scenario, the F5 load balancer tacked on a session cookie along with the HTTP response from the SharePoint WFE. The cookie identified to the load balancer which WFE was serving the user. Our network admin made a couple of changes to the way the F5 device was load balancing and we have no longer had the locking issue. I don't know the details, but he mentioned something about "performance layer 4" (one-to-many router setting) and changing the sticky sessions to be based on source address (i.e. the user's IP address).

    Looks like it won't help dbturtle any longer, but maybe this info can help keep others from taking the same abandonement approach.

    Tuesday, August 24, 2010 7:51 PM
  • Dbturtle,

    Sorry that you are having issues.  The issue here is the version of Office that you are using.  Are you using Office 2003 or Office 2007?

    With Office 2003 it is not a full integration with SharePoint 2007 because Office 2003 was out prior to SharePoint 2007.  Because of this Office 2003 does not have the proper mechanism to lock the files in SharePoint.  If your clients are running Office 2003 then your document library should not be set to required checkout. 

    Office 2007 should not have these problems because it was built to work with MOSS 2007 and has a full integration.  It knows how to lock the file correctly.

    Hope this helps,

    -Aseem

     


    This posting is provided "AS IS" with no warranties, and confers no rights
    Tuesday, August 24, 2010 8:50 PM
  • Glad it worked for you. We aren't using a load balancer, just a single front-end server.
    Wednesday, August 25, 2010 2:21 PM
  • We have always been using Office 2007 (and MOSS 2007). So the issue is not the version of Office.

    We also don't require checkouts.

    Thanks for trying.  Everybody seems to have a hard time believing this is a SharePoint bug, but we have hundreds of instances of it happening on diverse computers, from Windows XP to Windows 2008 Server, and two high-quality, certified Microsoft partners have tried to fix the problem unsuccessfully.

    Wednesday, August 25, 2010 2:27 PM
  • Hello,

    I understand your frustration.  I would not go as far to say this is a bug since this seems only to be affecting you and most often it is something environmental causing it (like a load balancer).  I would suggest you open a ticket with Microsoft Support and ask for the Office Client SharePoint Integration team.  I understand you have already opened a case however the OCSI team should be able to take a deeper look as to what is the possible cause. 

    Thanks,

    -Aseem


    This posting is provided "AS IS" with no warranties, and confers no rights
    Wednesday, August 25, 2010 2:58 PM
  • Thanks for your suggestions. In this case, the locking problem was only one of a dozen serious problems we experienced. Others were: all documents suddenly becoming read-only for an individual user, invalid "last modified" times, documents that enter a document library but can't be retrieved, failures when many people read the same file quickly, SharePoint rejecting documents with an unrecognized file attribute, etc etc etc), some of which Microsoft did acknowledge as SharePoint bugs.  In contrast, our other large, installed systems typically run for months without a single problem, and with very small support staff. That's why we've retired SharePoint.
    Wednesday, August 25, 2010 3:09 PM
  • Hi,

    Another way to get around this issue is to make the session sticky on the load balancer the way you normally would when using SSL. This would ensure that when you authenitecicated to one of the load balanced nodes you would continue to use this node until the end of the session...

     

    -Ivan


    Ivan Sanders My LinkedIn Profile, My Blog, @iasanders.
    Tuesday, August 31, 2010 2:18 AM
  • Sorry to hear about your troubles, but it sounds like this issue was unique to your environment.  Perhaps it was not configured properly initially?  I have been working with SharePoint for 5 years now in some very large organizations and have never run into any of these issues, even at high-traffic times. 
    Tuesday, August 31, 2010 4:41 PM
  • Ivan is right: in a load balanced scenario with multiple WFEs, sticky sessions is a must. We have discovered, however, that how you setup the sticky sessions is also important. Our load balancer (an F5 Big-IP) did not handle the file locking properly with our initial sticky sessions configuration. See my August 24 post in this thread for more info.
    Wednesday, September 01, 2010 3:06 PM
  • We are using SP 2007 and Office 2003. We rolled out SP a few weeks ago and this File in Use message is causing users to use docs off the FileServer - we know what a nightmare it can be when users are updating various versions of the same document. One, they don't understand the difference - Two, they just want to get their work done. Getting a message that says you can't edit the item, though it says you are the one that has the item locked for editing, is a real show stopper for the end user.  To this point, we have not seen a consistent pattern in when this File in Use box displays. It might happen the first time you go to edit your checked out doc, or the 10th.

    Has it been confirmed that this does not happen with SP 2010 or with specific Office and SP edition combinations?

    Thanks, Teresa

    Monday, September 20, 2010 4:44 PM
  • So I found I was also having this issue, and did a fair amount of scouting to find no reasonable solution.  The cause of my case might be different to yours, but I'll tell you what I found regardless.  The symptoms were similar to the OP, however after 10 minutes the file was still checked out and I couldn't understand why.  I left the file open in Word with notify on, then checked in the file in SP and noticed that the lock was dissappearing.  However, when I tried to "Edit in Word" again, the file showed as locked by "Me".

    So the root cause of my issue here was that as I understand it, MSWord and SharePoint don't pass credentials between one-another.  This means if there is a previously stored credential in Windows Credential Manager (I have Win7 here), MSWord will try to open the document with these credentials.  This becomes confusing to the user, as if they are logged into SharePoint as User A, but User B is stored in the Credential Manager, SharePoint will lock the file as User A then MSWord loads as User B and says that User A has it locked (*DOH!*).

    The simple (although slightly complicated for a layperson) fix for this is to load up Credential Manager and remove the stored password for the SharePoint server, requiring the user to log in once more. You can also use cmdkey /delete:servername as a scripted solution for this - possibly in login scripts? But I'm unsure of the standard lifespan of cached credentials in Credentials Manager.  I'm using cmdkey for demos and testing anyway.

    As this is a bit of a corner case, I can understand why it has been overlooked - it's not usual for multiple people to be logged into SP under the same Windows user account.  However, it's a real hum-dinger from a testing / demos point of view.  It also prompts the question - why in this case aren't the users' credentials more visible at least in MSWord if loading from a file share or SharePoint - so at least users can check and identify/fix the issue?  Would also be good in this case to have a "Open document as another user" menu item in Word :)

    Anyway, hopefully this helps someone.

    Cheers,

    Gavin

     

    Thursday, November 04, 2010 10:15 PM
  • Oh, and PS: this issue seems to be further complicated by the fact that Word doesn't reload it's credentials from Windows Vault unless all instances of Word are closed.  I need to test this further to confirm, but appears to be the case.

     

    Cheers,

    Gav

    Thursday, November 04, 2010 10:27 PM
  • Same problem I think.. excel spreadsheet is locked by my computer.  I've rebooted etc,  sharepoint also says that it's locked by my computer. I think logged onto a different computer and was able to edit the spreadsheet with no issue.  So, then I hit "notify" and waited, after a couple minutes finally got a message saying read/write is available. Let's see how long this lasts. 
    Monday, November 29, 2010 6:20 PM
  • WE have the exact same issue described by dbturtle in our organisation with a single WFE.

     

    Also this is just one of a couple of issues we have with files saved in sharepoint

    Sunday, January 16, 2011 7:11 PM
  • I can confirm that this bug (which it simply is) is still alive in SharePoint 2010...

    We're running SharePoint 2010 together with Office 2003 on some pc's and Office 2007 on other pc's (we're in the middle of upgrading all PC's). We're facing this bug in a document library that doesn't require checkout/approval, so a default out of the box document library.
    We're facing it on both Office 2003 and 2007. So it has nothing to do with an Office version that was not build for SharePoint.

    We're only having this on Excel files? Other files (word eg) work ok.

    When we try to open the excel file from SharePoint (context menu > edit in Microsoft Excel), nothing happens at all. No message, no excel opening, nothing, nada.
    When we try to open the excel file directly from Excel (navigating to the SharePoint location), we get the message that the file is locked for editing by 'another user'.

    Waiting for 10 minutes doesn't solve the problem
    Cleaning the Content.MSO folder doesn't solve the problem
    Checking out the document, then checking in, doesn't solve the problem

    We are on a single WFE, so no balancer that can cause trouble.

    Unfortunately we have a manager that is blind for all the extra trouble that SharePoint brings into an organisation only because it looks so fancy, so I have to deal with it someway and chances are low that we can manage to abandon SharePoint for good. But there doesn't seem to be a solution for this problem, and Microsoft seems to ignore that this is a bug in their system.

    So now what?

    Wednesday, March 23, 2011 9:47 AM
  • lmao....

    ...seems we are all sharing the point....lolz...

    There is no SharePoint expert anywhere in my little experience whose heart hasn't bled one way or the other...anyone?...nah, none.

    And there is no non-SharePoint pro anywhere who dabbled into by virtue of cross-functionalities who will not tell you, "SharePoint is crazy men!"...or, "It's a whole new world on it's own men!"...

    So, the both good and bad thing is, we are all stuck in this tech....and we have to support it to crazy clients, insane managers, dumb stakeholders and all funny sorts of people....

    ...and you know what?

    Behind our back as we walk past, they'll say, "That's the crazy dude who supports that crazy app...he's genius!"

    That is what they always think of us, geniuses! They don't know how we always do it, we always did it, solve it!

    lmao!


    You've only got ONE LIFE; HELP as many people as you can, and ENJOY IT while it lasts. People are in the centre of our happiness, even God understands that.
    Wednesday, March 23, 2011 11:13 AM
  • In some cases when i have run into this problem, I have found that SharePoint stores a copy of the document in the SharePoint drafts folder. The location is C:\Documents and Settings\username\My Documents\SharePoint Drafts.

    Deleting the document from this folder has solved the issue for me. But again, this is a solution for one particular client and not all of them.

    Also, it would be worthwile to check the web client service on the machine. Although used for webdav, but worth a try.

    >We're running SharePoint 2010 together with Office 2003 on some pc's and Office 2007 on other pc's (we're in the middle of upgrading all PC's). We're facing this bug in a document library that doesn't require checkout/approval, so a default out of the box document library.
    We're facing it on both Office 2003 and 2007. So it has nothing to do with an Office version that was not build for SharePoint.

    We have tested this with Office 2010 and this seems to allow simultaneous editing of documents using Office Web apps. Not sure with previous versions of Office though.

    Wednesday, March 23, 2011 1:11 PM
  • Hi VikSrini

    I checked the Drafts folder but the file is not there, so that didn't help either.
    I guess that would only be the case if I got the message that the file is locked by myself ? But in my case it's locked by 'another user'.

    Where/how do I check this web client service ?

    We don't use Office Web Apps, would be pointless since every user has Office on his PC, and SharePoint is only accessible from these PCs.


    Thursday, March 24, 2011 7:43 AM
  • Office web applications can be implemented with SharePoint 2010.  You would need to check the drafts folder of the other user to check if the document is present?

    Web client is a windows service active on each client. If you go to start>run and type services.msc you should see it there.

    Thursday, March 24, 2011 1:56 PM
  • We have similar issues. In our case, the number of reports (and frustrated users) continues to grow weekly.

    I have seen the above. I have seen cases where MOSS (SharePoint) 2007 SP1 (using sql server 2005) says the document is checked out by someone else, even though that person denies ever checking out the document.

    The most recent manifestation is even stranger - user in owner group for a site can get Excel 2003 to open the spreadsheets when item is not checked out. However, if the person checks the document out and then immediately attempts to open the document, he only gets a blank screen - excel does not start up.  No error message, no application. Just a blank screen.


    Thursday, March 24, 2011 3:57 PM
  • Office web applications can be implemented with SharePoint 2010.  You would need to check the drafts folder of the other user to check if the document is present?

    Web client is a windows service active on each client. If you go to start>run and type services.msc you should see it there.


    In our case, we don't want Office Web Apps, even though it is supported by SP2010. Every machine has it's own Office installation.
    SharePoint is not even able to work with that, so we're not planning to bring in more problems by implementing web apps.

    I've checked the services on my machine (we're I'm having this issue as well), and the services has started (automatically). So I don't think that will be the issue in my case ?

    Just like lvirden, we get a growing number of reports each day by end users on this problem and yet no solution at all by Microsoft...

    Tuesday, March 29, 2011 6:57 AM
  • I agree: Office Web Apps is not a viable solution to this problem. The feature set available in Office Web Apps can not compare to the features available in the client app. Due to the limited feature set, Office Web Apps rarely works as an enterprise-wide replacement for the client.

    I feel for you guys. It was a huge headache for me when I was getting this problem, too. Watching the network traffic with Fiddler is what led us to our load balancer as the culprit. The networked request from Office to SharePoint to lock/unlock the file was failing. Even though you have a single WFE, I would still recommend inspecting the network traffic. There may be something else in your network (a switch, router, hub, etc.) that is causing problems with a request somewhere along the line. If nothing else, you mayat least see that the traffic is all clear and can scratch my solution off your list.

       ---PaulE---

    PS--We've had no troubles with our SharePoint Server 2010 farm which was deployed after our solution was found.
    • Proposed as answer by AseemN Monday, May 16, 2011 7:55 PM
    • Marked as answer by Mike Walsh FIN Tuesday, May 24, 2011 10:05 AM
    Thursday, March 31, 2011 7:25 PM
  • Hi Paul,

    We rebooted all servers, and for now the problem seems to be gone. We have no idea what caused it, and we hope that we won't see it again.

    We're currently migrating all content to a brand new SharePoint 2010 installation, so we'll see if it occurs in this new environment as well.
    If it does, I'll ask our infrastructure guys to monitor the network traffic to identify possible causes. In this new environment we'll be using a load balancer, so at least now we know that this may cause problems.

    Thanks for the advice :)

    Friday, April 01, 2011 7:17 AM
  • We also had this same issue but was resolved in a different way.

    The following blog pointed me in the right direction

    http://yagyashree.wordpress.com/event-id-8214-object-reference-not-set-to-an-instance-of-an-object/

    In our case, a user was using an old DNS CNAME to access sharepoint which was not in the list of "known" URLs listed in Alternate Access Mappings.  If your users refer to your server by any urls other than what's in this list, you may see the "file locked" issue.  Once we removed the CNAME and forced the user to use a "known" URL, they were able to open the word documents just fine.


    Shane Powser
    Wednesday, April 20, 2011 10:54 PM
  • Is anyone still having this issue? I am and cannot seem to solve. I have looked into and tried everything on this post and have a case open with Microsoft. Any help would be greatly appreciated.

    Some details:

    Coming in via HTTPS through ISA 2006

    SharePoint: WSS 3.0 SP 3 (12.0.0.6535) with 1 WFE, 1 App/Index running on Win 2003 R2. SQL 2008 on Windows 2003 ( Clustered ) - All 32 Bit

    Clients: Win 7 SP1 and Office 2010 - mix of 32 and 64 bit

    Clients with XP and Office 2003/2007 DO NOT have this issue.

    Thanks

     

    Monday, May 09, 2011 1:33 PM
  • I'm still having this issue. Last time I had it was last week.

    None of the solutions/workaround that I've found on Google and these forums solves it, and Microsoft is simply ignoring the problem.

    In our case:
    - coming in via HTTP
    - SharePoint 2010 Enterprise (14.0.4763.1000) with 2 WFE, running on Win 2008 and SQL 2008 (clustered) - all 64 bit
    - Authentication: Active Directory
    - Clients: Win XP Professional Version 2002 SP3 and Office 2007 (12.0.6514.5000) SP2 MSO (all 32bit).

    So in our case Win XP and Office 2007 do have this issue.



    Tuesday, May 10, 2011 7:45 AM
  • I understand that most of you are having this issue and I feel for you.  From my experience with this error 99% of the time the problem is caused by a network problem and not a SharePoint issue.  The other 1% it is due to a customization or corrupt web app.  I would suggest as PaulE states above is to examine what is happening in the network traffic.  Another suggestion I have is to create a new out of the box plain Web Application.  Does the same errors occur in a new Web App?  If not then you know it is not a client side problem. 

    What lies between the client and SharePoint?  ISA server?  Another Proxy?  A load balancer?  A router?  Bypass layers until you find the culprit and then troubleshoot the culprit. 

    -Aseem

     

     

     

     


    This posting is provided "AS IS" with no warranties, and confers no rights
    Monday, May 16, 2011 8:06 PM
  • In my case, we are submitting the form within the LAN, no ISA/proxy/router. Sometimes, it goes through. Otherwise the workflow hangs up because of the error 'Currently the item is locked by the <user>'.
    Thursday, May 19, 2011 5:39 PM
  • I'm locking this thread.

    At 45 posts it is already massively unwieldy and it is starting to attract posts from people running SP 2010 who seem blissfully unaware that SP 2010 is off-topic in the pre-SP 2010 forums (and in threads about problems with pre-SP 2010 products).

    Moderator pre-SP 2010 forums

    If you have similar problems with a pre-SP 2010 product, please start a new thread.

    If  you have similar problems with a SP 2010 product please look for a SP 2010 forum to post to.

     


    SP 2010 "FAQ" (mainly useful links): http://wssv4faq.mindsharp.com/default.aspx
    WSS3/MOSS FAQ (FAQ and Links) http://wssv3faq.mindsharp.com/default.aspx
    Both also have links to extensive book lists and to (free) on-line chapters
    Tuesday, May 24, 2011 10:08 AM
  • http://social.technet.microsoft.com/profile/jinchun%20chen/ had just demoed me the issue in Windows Explorer View, and referred me to the SPFile.Lock, SPFile.LockType, SPFile.ReleaseLock. I can view the information with .net reflector and PowerShell. For example, with PowerShell:

    $w=get-spweb http://mysharepointsiteurl/

    $f=$w.getfile("/documents/mydocname.docx")

    $f

    I can see the LockType, Lockid, LockedDate, LockExpire, LockedByUser, CheckOutStatus .... properties value returned. And I can clear the lock with:

    $f.releaselock($f.lockid)

    or $f.releaselock({theGUIDofTheLock})

    What really arouse my interest is:  I had not find similar lock property in SPListItem.

    SharePoint provide handy item level permission system you all know like Windows, and field index(http://www.c-sharpcorner.com/UploadFile/d2ee01/sharepoint-2010-internals-%E2%80%93-series-2/) , which, a lot of people, including me don't know very well. However, can I find some locking system which can support transaction like in SQL server? I would dive into AppFabric Distributed Caching in SharePoint 2013 first.

    Thursday, March 14, 2013 3:56 AM
    Moderator