views:

337

answers:

1

Hi All,

I've just encountered what appears to be a really annoying "feature" in SharePoint (it may be by design, but the scope of that is probably beyond this question).

I am helping to develop an application that retrieves files and their version history for specific files stored on SharePoint. This information is uploaded to a data warehouse, one of the critical fields we need to capture is the time the file version was originally uploaded (i.e. created) onto SharePoint.

Initially this appeared to be fairly straight forward, using the (SharePoint WebServices) version service (versions.asmx) we called:

SPVersion.GetVersions(fullpath);

Which returns us an XML result similar to below (including a field called "created"):

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"&gt;
  <soap:Body>
    <GetVersionsResponse xmlns="http://schemas.microsoft.com/sharepoint/soap/"&gt;
      <GetVersionsResult>
        <results xmlns="http://schemas.microsoft.com/sharepoint/soap/"&gt;
          <list id="{guid}"/>
          <versioning enabled="1"/>
          <settings url="http://SITE/_layouts/LstSetng.aspx?List={guid}"/&gt;
          <result version="@6.0" url="http://SITE/PATH/FILENAME" created="12/8/2009 11:58 AM" createdBy="DOMAIN\USER" size="149504" comments=""/>
          <result version="1.0" url="http://SITE/_vti_history/id/PATH/FILENAME" created="12/7/2009 4:10 PM" createdBy="DOMAIN\USER" size="148992" comments=""/>
          <result version="2.0" url="http://SITE/_vti_history/id/PATH/FILENAME" created="12/8/2009 11:32 AM" createdBy="DOMAIN\USER" size="149504" comments=""/>
          <result version="3.0" url="http://SITE/_vti_history/id/PATH/FILENAME" created="12/8/2009 11:45 AM" createdBy="DOMAIN\USER" size="149504" comments=""/>
          <result version="4.0" url="http://SITE/_vti_history/id/PATH/FILENAME" created="12/8/2009 11:49 AM" createdBy="DOMAIN\USER" size="149504" comments=""/>
          <result version="5.0" url="http://SITE/_vti_history/id/PATH/FILENAME" created="12/8/2009 11:58 AM" createdBy="DOMAIN\USER" size="149504" comments=""/>
        </results>
      </GetVersionsResult>
    </GetVersionsResponse>
  </soap:Body>
</soap:Envelope>


All well and good, until you look closely at the created field - versions 5 & 6 have exactly the same created date. Further investigation revealed to me that ALL versions of the document have a created datetime that matches the actual created datetime for the next version of the document. I.E. When I check SharePoint and look at the version history I can see version 2 was actually created at 16:10, the time that is showing above for version 1.

I am assuming that the created field is NOT actually the created field, but is a modified field that takes into account when the file was modified and made an "older" version.

Has anyone encountered this problem and found a reliable way to get the versions service to return the actual time of creation of the file, or - using the information above - is there a reliable mechanism to get the time on the file?

Note that we cannot use the SharePoint API / DLL's for this project.

Thanks Chris

A: 

If you dont have access to the API, wouldn't getting the smallest version's created field satisfy your rule? In your case, version 1.0.

Just document in your consumer why you need to do that and how the behavior by design made the decision on how to get this value.

You can also check if accessing the actual document/item will give you the correct created date, not resorting to the history system for that.

F.Aquino
I was considering something similar, and then pairing the items off to the previous generation to get the value - but this seems like an unreasonable hack. I can do it if I need to - but there surely MUST be a better way, it can't be unusual to want to know when a version was created?
Chris
in my experience, the version system is glitchy in many ways, for example, if you rename a file all the old versions get the new extension, ie.: you start with a Report.docx and then the user a few versions later discovers the wonders of excel and uploads a Report.xslx over the file (custom system here), now all the past versions are .xslx even tho the content is a docx file.
F.Aquino
lol, really? oh dear.... yes, your experience sounds like a roadmap for how I think mine is going... im currently exploring an option using the lists.GetVersionCollection to get the info I want, but already getting a bad feeling. If I hit the wall will give your approach a try
Chris