<Eq>-CAML delivers wrong result

Question

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)

Answer 1

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

Answer 2

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!

Answer 3

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

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