1

We have the sharepoint 2010 environment with Document ID's enabled.

Given (part of) a Doc ID, we want to programmatically retrieve the document(s) matching that ID. The problem seems to be that this column is rather special, in that it might need special handling.

Using an SPSiteDataQuery, fetching the _dlc_DocId field as part of the viewfields works fine. However, including it as part of the where query never results in any documents being fetched.

Using the Search API has gotten us nowhere at all.

Has anyone pulled this off, or any suggestions on how to tackle this problem?

[Update] Turns out we were fooled by subtle errors in the XML and bad debugging misinterpretations. This stuff just works fine.

Improve this question

3 Answers 3

Reset to default
4

I don't normally contribute to these sorts of things because cleverer people than I always get there before me, but as this is an old one with no proper answer I think I'll add my thoughts for those who find this page.

I was struggling with this but after a little digging around and learning a bit of Caml I got this working. I am using the SharePoint Client Object Model against SharePoint 2010 and Office365 beta.

Start off your query by looking at the all list items query:

Microsoft.SharePoint.Client.CamlQuery.CreateAllItemsQuery().ViewXml

"<View Scope=\"RecursiveAll\">\r\n <Query>\r\n </Query>\r\n</View>"

Stick a where child inside the query

Then add in

<Eq><FieldRef Name="_dlc_DocId" /><Value Type="Text">MDXC2KE55ASN-3-80</Value></Eq>

replacing MDXC2KE55ASN-3-80 with the doc ID you are looking for inside the where.

Also don't forget you might want to make use of these too:

<ViewFields><FieldRef Name="_dlc_DocId" /></ViewFields>

<RowLimit>1</RowLimit>

Then use List.GetItems() method to bring back the ListItemCollection.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

You are right, thanks for taking the time to post your answer. Since asking the question, we have figured out it does work after all, exactly the way you describe it (this code has long move into production). We just query the SharePoint object model directly, rather than through a webservice call.
0

Just in case nobody comes with a slick solutions from the depths of the Sharepoint infrastructure:

What would Google Do?

Slice is, Dice it and dump it in a reverse index.

Solr and Lucene offer supreme tools for this. The idea is to cut the DocId's in small pieces and add the location of the document to the bucket for that piece.

Say We have "A real nice document" with Id ABCD123. You would add it to the buckets

ABCD, BCD1, CD12, D123

When searching for a partial ID (+ other data like dates, types, ...) you (well the search engine) creates the union of the buckets + applies additonal constraints.

To make this happen you need to write a spider for the sharepoint server and a routine which makes a record of data elements to be indexed.

Put a nice REST interface in frnt of it (actually SOLR already has that), integrate it in the main sharepoint server, and nobody needs to know there is something else running behind it.

These products can also incrementally update the indexes, so they can be kept up to date.

Improve this answer

Comments

0

you could use the following to get the Document ID.

SPFile file = MethodToUploadFileToServer(web, filepath); SPListItem item = file.Item; string DocID = item.Properties["_dlc_DocId"].ToString();

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.