function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
RichardRichard 

Incorrect ID being returned when querying using the v2.0 API since Winter '06 release

Hello


We've encountered another problem with the v2.0 API via Java that has arisen since the Winter '06 release.


Queries against CONTACT are returning the same ID no matter what the criteria.


A sample from our logs is below:


Code:

processing rule : pre_import_integrity_check for entity : contact 
Complex Query result=FOUND value=00320000000Llvb {Entity=contact}
{Values: email=david.peters@xxxxx.com.au lastName=Peters }
{Selecting=id}{Query='email' 'equals' 'file:CORP_EMAIL' 'and' 'lastName' 'equals' 'file:CORP_LASTNAME'}
....................................................................................................
processing rule : pre_import_integrity_check for entity : contact
Complex Query result=FOUND value=00320000000Llvb {Entity=contact}
{Values: email=adam.dubojski@xxxxx.com.au lastName=Dubojski }
{Selecting=id}{Query='email' 'equals' 'file:TECH_EMAIL' 'and' 'lastName' 'equals' 'file:TECH_LASTNAME'}
...................................................................................................
processing rule : pre_import_integrity_check for entity : contact
Complex Query result=FOUND value=00320000000Llvb {Entity=contact}
{Values: email=ap.grafton@xxxxx.com.au lastName=Payable }
{Selecting=id}{Query='email' 'equals' 'file:BILL_EMAIL' 'and' 'lastName' 'equals' 'file:BILL_LASTNAME'}
...................................................................................................
processing rule : create for entity : case creating new:case
Complex Query result=FOUND value=00320000000Llvb {Entity=contact}
{Values: email=david.peters@xxxxx.com.au lastName=Peters }
{Selecting=id}{Query='email' 'equals' 'file:CORP_EMAIL' 'and' 'lastName' 'equals' 'file:CORP_LASTNAME'}

----------------------------------------------------------------------------------------------------
System Error Message : The remote application issued this error: insufficient access rights on
cross-reference id
----------------------------------------------------------------------------------------------------


 


Above shows 3 seperate queries for CONTACTs that all successfully return the same ID value that refers to another contact entirely.


The criteria for the query uses email and lastName. Both of these are standard CONTACT fields (NOT Custom fields) as returned by the describe call.


The contacts Peters and Dubojski exist within SF but Grafton does NOT yet all queries seem to be successful.


The incorrect ID is not for any of these contacts.


The end result is that our code creates a case that is linked to an incorrect contact.


The "insufficient access rights" error was fixed by Salesforce on 11 Jan (Australian time)


Late addition: We are seeing similar behaviour when querying against ACCOUNT also using criteria of "name", "billingCountry" and "billingState"


 

SuperfellSuperfell
did you log a case for this ? do you have a capture of the request xml ?
RichardRichard



SimonF wrote:
did you log a case for this ? do you have a capture of the request xml ?




Hello Simon,


Case raised: 0067922


I'm trying to get a SOAP request for you now. Will add it to the case when/if I can get it.



 

RichardRichard

Case has been updated with a sample SOAP request


From local testing it seems that the filtering is being ignored which results in the wrong data being returned.
Instead of this query returning a single row result (usually) it is now returning many rows. None of which match the filter options.



 





Richard wrote:






SimonF wrote:
did you log a case for this ? do you have a capture of the request xml ?







Hello Simon,



Case raised: 0067922



I'm trying to get a SOAP request for you now. Will add it to the case when/if I can get it.





SuperfellSuperfell
Thanks, the capture of the request helped a lot. This is a regression with Winter 06, the fix should go out soon. In the meantime, a workaround is to not send the ifModifiedSince element, the query will do the right thing when that's not there.
SuperfellSuperfell
The fix for this is live now.