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"

 

Hi Gang,

Another one of our Salesforce integrated applications (in existence for several years) has been returning the above error since last weekend (Winter '06 Release)

We are talking about the 2.0 version of the API using Java & SOAP.

Basically, the code makes a "describe" call to return all the metadata about the opportunity entity and then uses some of the returned names in a "query" call.

It is as though we are no longer about to query custom fields using the names from the describe call. (Querying using NON custom fields only seems to still work, but that isn't useful to me)

Does anyone know what is going on here? Is this my problem or a problem with Salesforce?

I'd appreciate any help you can give.

Thanks,

Tony

Hello,

We have code that was running successfully on Friday 6 January but began failing over the weekend with the error: "Insufficient access rights on cross-reference id" whilst trying to create CASEs.

(Our code has not been changed. Java SOAP API version 2.0, (Code was written in 2003))

Am I right to suspect the Winter '06 release for breaking things?

Can anyone provide a detailed explanation for the error message that might give me a hint of what is going on?

Thanks,

Tony

Hi,

I download the Java Getting Started Package, unzip it, include jre in window class path, then I run the quickstart.bat. I choose "1. Login", then type in User name and password, and I get the following exception:

nested exception is: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted certificate found

Could anyone help?

Thanks.

I'm using the 2.0 version of the api to query data using complex query filters.

I have not noticed this problem before but when I build a complex query using a phrase as the value to search for which contains punctuation such as a full stop, the query never returns any results.

should I expect this behaviour?
Should I be encoding my search values in some way?

If anyone can point me in the right direction on this one I would be very grateful.

All the best,
Richard

Hi.

I'm trying to create a complex query that can be made up of 2-n conditions by parsing a psuedo sql statement. This is working fine when using just 2 statements. when I up this to 3 statements the code bombs out with a stack overflow error.

Algorithmically I am:

creating a simple Query statement.
creating a second simple query statement.
combining these into a complex query using makeAndOrFilter function.

creating a third simple query statement.
combining this into a complex query using the makeAndOrFilter funtion and the previously created complex query.


Is the nesting of queries in this way supported? or can I only create complex queries when I have an even number of query statements to use as the example QueryFilter.java file?

my succesfull soap request is detailed below:


OST /servlet/servlet.SoapApi HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.1
Host: na1-api.salesforce.com
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: "sfconnector:SalesforceConnector#query"
Content-Length: 2836





s23uXwpju4AY_wPjB1t.K.VclJYSpLhLHkoVtihD5pMHQNt0.3NyFs6j_tlxtBQiBK_XYAh9q6xyi4Rib7quMvbtzKggVlhL
2.0




filter
user
1

id




value



field
username


value
joe.bloggs@address.com.au


operator
equals




field
firstName


value
Joe


operator
equals





operator
and




1970-02-01T06:03:16.838Z
false

Message Edited by Richard on 10-17-2003 10:26 AM

I'm developing with the SOAPAPI and am wanting to invoke the rate limiting by adding the header: RateLimitAdd and giving it a value (as suggested in the docs) of 80000.

If I am taking the example code and modifying it to invoke the rate limiting - where does the header need to be set and how?

My first approach was to modify the HeaderStruct class to include rateLimitAdd as a new field and setting it with a value in the same way that the session id is set. this had no effect.

Any pointers?

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"

 

We were connecting to the SalesForce endpoint with the following URL:
http://www.salesforce.com/servlet/servlet.SoapApi
(old version of the API).

Since this morning, that URL no longer seems to be valid.

Anyone know if this is permanent? If so, is there a new URL?

Thanks,
Mike

Hi Gang,

Another one of our Salesforce integrated applications (in existence for several years) has been returning the above error since last weekend (Winter '06 Release)

We are talking about the 2.0 version of the API using Java & SOAP.

Basically, the code makes a "describe" call to return all the metadata about the opportunity entity and then uses some of the returned names in a "query" call.

It is as though we are no longer about to query custom fields using the names from the describe call. (Querying using NON custom fields only seems to still work, but that isn't useful to me)

Does anyone know what is going on here? Is this my problem or a problem with Salesforce?

I'd appreciate any help you can give.

Thanks,

Tony

Hello,

We have code that was running successfully on Friday 6 January but began failing over the weekend with the error: "Insufficient access rights on cross-reference id" whilst trying to create CASEs.

(Our code has not been changed. Java SOAP API version 2.0, (Code was written in 2003))

Am I right to suspect the Winter '06 release for breaking things?

Can anyone provide a detailed explanation for the error message that might give me a hint of what is going on?

Thanks,

Tony

Hi,

I download the Java Getting Started Package, unzip it, include jre in window class path, then I run the quickstart.bat. I choose "1. Login", then type in User name and password, and I get the following exception:

nested exception is: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted certificate found

Could anyone help?

Thanks.

 

Hi all,

I'm trying to run a query for an account object that has a particular social sec. # (a custom field), but I keep on getting a message saying "Bad field name 'site' in select list of query call".   Is there something I'm missing? I verified I'm using API version 2.0 and verified the WSDL has "SSN_c" as the field name .  Here's my code:

    Object[] filter = new Object[1]; //Final filter array
    Calendar jc = Calendar.getInstance();
    jc.set(1950,10,6);
    filter[0] = makeSimpleFilter("SSN__c", sSqlRetData, "equals");

    org.w3c.dom.Element a_value = (org.w3c.dom.Element)   binding.query("filter", "account", 10,
               new java.lang.String[] {"SSN__c"}, filter, null, jc, true);

Thanks in advance for any help.

KC

 

Message Edited by kevincar on 12-11-2003 01:57 PM

I'm using the 2.0 version of the api to query data using complex query filters.

I have not noticed this problem before but when I build a complex query using a phrase as the value to search for which contains punctuation such as a full stop, the query never returns any results.

should I expect this behaviour?
Should I be encoding my search values in some way?

If anyone can point me in the right direction on this one I would be very grateful.

All the best,
Richard

Hi.

I'm trying to create a complex query that can be made up of 2-n conditions by parsing a psuedo sql statement. This is working fine when using just 2 statements. when I up this to 3 statements the code bombs out with a stack overflow error.

Algorithmically I am:

creating a simple Query statement.
creating a second simple query statement.
combining these into a complex query using makeAndOrFilter function.

creating a third simple query statement.
combining this into a complex query using the makeAndOrFilter funtion and the previously created complex query.


Is the nesting of queries in this way supported? or can I only create complex queries when I have an even number of query statements to use as the example QueryFilter.java file?

my succesfull soap request is detailed below:


OST /servlet/servlet.SoapApi HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.1
Host: na1-api.salesforce.com
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: "sfconnector:SalesforceConnector#query"
Content-Length: 2836





s23uXwpju4AY_wPjB1t.K.VclJYSpLhLHkoVtihD5pMHQNt0.3NyFs6j_tlxtBQiBK_XYAh9q6xyi4Rib7quMvbtzKggVlhL
2.0




filter
user
1

id




value



field
username


value
joe.bloggs@address.com.au


operator
equals




field
firstName


value
Joe


operator
equals





operator
and




1970-02-01T06:03:16.838Z
false

Message Edited by Richard on 10-17-2003 10:26 AM