+ Start a Discussion
DrawloopSupportDrawloopSupport 

Sf Query in Execute JavaScript Button returns: INVALID_TYPE: sObject type '...' is not supported

Can anyone think of a reason an execute javascript button would cause this error while the same query in the Salesforce Explorer does not? The object is deployed. The API name of the object is typed correctly. The user's profile has access to the object. The user logged in to the explorer is the same user logged into the browser in Salesforce.

 

Any ideas would be terrific.

 

Thanks!

werewolfwerewolf
Have you tried putting a breakpoint in that code with Firebug to ensure that you're sending the query you think you're sending?
SuperfellSuperfell
Is your button part of a managed package? packages access controls can mean that your button has less visibility than the same user via apex explorer.
DrawloopSupportDrawloopSupport

It seems very difficult, if not impossible, to debug an execute javascript button with Firebug. The query is not dynamic except for the Id part:

 

SELECT Field__c FROM Object__c WHERE OtherField__c='value' AND ParentId__c='IdValue'

 

The error is happening on the Object__c part of the query, but it works through the explorer.

DrawloopSupportDrawloopSupport

Simon,

 

The button is not part of a managed package.

 

Thanks.

SuperfellSuperfell
Your 2 tests are using the same API version ?
DrawloopSupportDrawloopSupport

Using API version 16 in both the execute javascript and the explorer. In the execute javascript button, here is what the query looks like:

 

{!REQUIRESCRIPT("/soap/ajax/16.0/connection.js")} var accounts = sforce.connection.query("SELECT Field__c FROM BadObject__c WHERE OtherField__c='value' AND ParentIdField__c='{!Parent_Object__c.Id}'");

I have also tried doing a simple query in the firebug console like SELECT Id FROM BadObject__c LIMIT 1 and that throws the same error in the browser but not in explorer.

 

DrawloopSupportDrawloopSupport
Well, we found the problem. There is a request for version 8.0 of the SF API on the page, but we could not determine where the request is coming from. Changing the connection url (replacing 8.0 with 16.0) before making the query fixed the problem. I still don't see why version 8.0 of the API would not have access to this object, but we worked around it.