6

I have a strange problem, maybe someone here may have a helpful suggestion.

I have a list, with a Note-Field, containing a Url:

http://dev-wilma/results.aspx?r=owstaxIdGeschaeftsfallart:|fa543359-b22b-46f0-be44-1dc4b987dfac&#Default=%7B%22k%22%3A%22%22%2C%22r%22%3A%5B%7B%22n%22%3A%22owstaxIdFachthema%22%2C%22t%22%3A%5B%22string(%5C%22%23f192a44f-6423-4bdf-b082-a6aa8b36c0d7%5C%22)%22%5D%2C%22o%22%3A%22and%22%2C%22k%22%3Afalse%2C%22m%22%3Anull%7D%2C%7B%22n%22%3A%22SPContentType%22%2C%22t%22%3A%5B%22%5C%22%C7%82%C7%8250726f746f6b6f6c6c2d4c4154%5C%22%22%5D%2C%22o%22%3A%22and%22%2C%22k%22%3Afalse%2C%22m%22%3Anull%7D%5D%7D

However, If I do a query like this:

<Where>
    <Eq>
        <FieldRef Name='LinkedTo' />
        <Value Type='Note'>
            <![CDATA[http://dev-wilma/results.aspx?r=owstaxIdGeschaeftsfallart:|fa543359-b22b-46f0-be44-1dc4b987dfac&#Default=%7B%22k%22%3A%22%22%2C%22r%22%3A%5B%7B%22n%22%3A%22SPContentType%22%2C%22t%22%3A%5B%22%5C%22%C7%82%C7%8250726f746f6b6f6c6c2d4c4154%5C%22%22%5D%2C%22o%22%3A%22and%22%2C%22k%22%3Afalse%2C%22m%22%3Anull%7D%5D%7D]]>
        </Value>
    </Eq>
</Where>

(sorry for the Long URLs, but that's how they are)

it will still deliver me the entry with the above mentioned URL, although they are NOT equal and (and not even an Extension, because as you can see the shorter one Ends with an an "D" and the longer one has a "B" on that string position.

It doesn't make a difference, if a change the value-type to "Text" or use/don´t use CDATA.

So, do you have any suggestions?

UPDATE: This is used in Serverside OM, using the SPQuery-Object (of course same issue occurs in c# code and powershell)

  • Try to surround your <Where> statements with <Query> ones. – Alex Jun 30 '15 at 12:28
  • Are you using Client side code or Server side? It would be useful if you can update the code so that we all can see how you are executing the query. Also it's not very clear what do you mean by they are not equal. It's just I am unable to understand your question and may be many of us also aren't able too. – Taran Goel Jul 2 '15 at 6:27
  • I updated my question. They are not equal means, that the value in the field of the found entry is NOT the same value, as the one searched for (as in the query). Even afterwareds comparison of the 2 texts using "Equals" returns false. – Leopold Lerch Jul 2 '15 at 6:31
  • Just one more question, did you create this Note-Field OOTB or using code? (I am trying to replicate the issue). – Taran Goel Jul 2 '15 at 6:36
  • it is a custom field deployed using a solution. The declaration of the field is <Field ID="{B8981755-1B71-4464-9197-730D870D64E5}" Type="Note" UnlimitedLengthInDocumentLibrary="TRUE" Name="LinkedTo" DisplayName="LinkedTo" Overwrite="TRUE" Group="xxx"></Field> – Leopold Lerch Jul 2 '15 at 7:26
4
+100

I was able to reproduce what I believe is the same behavior.

There are two entries, one is bigger than the other.

Querying the big one, returns itself.

Querying the smaller one, returns both, although one does not contain the other.

If you fall short of solutions, this can potentially be a bug related to the complexity of the content. wouldn't be the first.

if you want to keep using CAML (as opposed to a "code" approach), you can try a double validation, adding both EQ and contains, which seems to help

function Get-ServerQuery($filterValue, $rowLimit)
{
    $query = New-Object Microsoft.SharePoint.SPQuery
    $query.Query = '
        <Where>
        <And>
            <Eq>
                <FieldRef Name="LinkedTo" />
                <Value Type="Note"><![CDATA[' + $filterValue + ']]></Value>
            </Eq>
            <Contains>
                <FieldRef Name="LinkedTo" />
                <Value Type="Note"><![CDATA[' + $filterValue + ']]></Value>
            </Contains>
            </And>
        </Where>
        '
    $query.RowLimit = $rowLimit
    $query.ViewFields = ""

    #returns array with 0 or more items
    return $query
}

$test5 = "http://dev-wilma/results.aspx?r=owstaxIdGeschaeftsfallart:|fa543359-b22b-46f0-be44-1dc4b987dfac&#Default=%7B%22k%22%3A%22%22%2C%22r%22%3A%5B%7B%22n%22%3A%22owstaxIdFachthema%22%2C%22t%22%3A%5B%22string(%5C%22%23f192a44f-6423-4bdf-b082-a6aa8b36c0d7%5C%22)%22%5D%2C%22o%22%3A%22and%22%2C%22k%22%3Afalse%2C%22m%22%3Anull%7D%2C%7B%22n%22%3A%22SPContentType%22%2C%22t%22%3A%5B%22%5C%22%C7%82%C7%8250726f746f6b6f6c6c2d4c4154%5C%22%22%5D%2C%22o%22%3A%22and%22%2C%22k%22%3Afalse%2C%22m%22%3Anull%7D%5D%7D"
$test6 = "http://dev-wilma/results.aspx?r=owstaxIdGeschaeftsfallart:|fa543359-b22b-46f0-be44-1dc4b987dfac&#Default=%7B%22k%22%3A%22%22%2C%22r%22%3A%5B%7B%22n%22%3A%22SPContentType%22%2C%22t%22%3A%5B%22%5C%22%C7%82%C7%8250726f746f6b6f6c6c2d4c4154%5C%22%22%5D%2C%22o%22%3A%22and%22%2C%22k%22%3Afalse%2C%22m%22%3Anull%7D%5D%7D"
$query = Get-ServerQuery $test6 10
$items = $list.GetItems($query)

write-host "Found "$items.Count
foreach($item in $items)
{
    $item["Title"]
}

web ok

list ok

testing test6

Found 1

test6

4

After much trying to replicate the issue, I finally did it. It seems to be a bug with CAML and it really baffled me that how can such a big bug is still unnoticed of. Though I kept trying different approaches to resolve it including the "beginswith" but that's not a proper solution. But while trying I did a double check and voila! it worked. Combining (beginswith and eq) or (contains and eq) returned the desired results. I'll write the used CAML query below:

<Where>
        <And>
            <Eq>
                <FieldRef Name="LinkedTo" />
                <Value Type="Note"><![CDATA[http://dev-wilma/results.aspx?r=owstaxIdGeschaeftsfallart:|fa543359-b22b-46f0-be44-1dc4b987dfac&#Default=%7B%22k%22%3A%22%22%2C%22r%22%3A%5B%7B%22n%22%3A%22SPContentType%22%2C%22t%22%3A%5B%22%5C%22%C7%82%C7%8250726f746f6b6f6c6c2d4c4154%5C%22%22%5D%2C%22o%22%3A%22and%22%2C%22k%22%3Afalse%2C%22m%22%3Anull%7D%5D%7D]]></Value>
            </Eq>
            <Contains>
                <FieldRef Name="LinkedTo" />
                <Value Type="Note"><![CDATA[http://dev-wilma/results.aspx?r=owstaxIdGeschaeftsfallart:|fa543359-b22b-46f0-be44-1dc4b987dfac&#Default=%7B%22k%22%3A%22%22%2C%22r%22%3A%5B%7B%22n%22%3A%22SPContentType%22%2C%22t%22%3A%5B%22%5C%22%C7%82%C7%8250726f746f6b6f6c6c2d4c4154%5C%22%22%5D%2C%22o%22%3A%22and%22%2C%22k%22%3Afalse%2C%22m%22%3Anull%7D%5D%7D]]></Value>
            </Contains>
            </And>
        </Where>

Great question and great find. I learnt something new Today. Thanks!

  • thanks, but as you provided somehow the same answer llike tiago some days ago, i´ll had to give the bounty to him. But I voted your answer up. Yeah, I too was very annoyed above this bug, but i guess it won´t be changed very soon. The problem is that I can´t rely on the results of <Eq> in the future anymore. – Leopold Lerch Jul 7 '15 at 7:37
  • I found the answer days ago but didnt get the time to update..:D Thanks though! @tiago Duarte deserves it!..Glad we could help.Cheers! – Taran Goel Jul 7 '15 at 7:39
0

You can try using beginswith or contains which often help with note fields

<BeginsWith>
<FieldRef Name = "LinkedTo"/>
<Value Type = "Text"/>
    blahblahblah
</Value>
</BeginsWith>

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.