+ Start a Discussion

System.QueryException: object is not accessible in query due to package restrictions

I have run into this error message when trying to use dynamic SOQL for the first time. I am running the query in a managed package, but the object I am working with is in the same managed package, the package api is unrestricted, and my profile is system admin with full rights. Can anyone think of any other settings that would be causing restricted access?

I was just about to post about this exact issue. I have my package setup the same as yours, with unrestricted API access, and I am getting this error message when trying to access even standard fields (such as Contact.FirstName). I also created a small test trigger outside the package, using the same code to access the property via Dynamic Apex and it works fine. However, if I add that trigger to my package, the trigger is then broken.

Sample trigger:

trigger Contact_Test on Contact ( before update )
System.debug( trigger.new[0].get( 'FirstName' ) );

This appears to be a Dynamic Apex + Packaging bug.
The reason that you can't access standard fields is because you would need to enable access restrictions on your package and require the standard objects (if you go to your package and click to enable restrictions, you will see that the standard objects are not checked).  On that same screen though, all objects of that package are already enabled so I don't understand why they would give this error.
My package does not the the ability to enable access restrictions because it contains s-Controls. My current setting is "Unrestricted [Package contains S-Controls]" and there is no option to change that. Unrestricted should give it full access to all objects and fields (and it does, outside of dynamic apex).

My package can access the objects and fields in question just fine if I access them via a strongly typed object instead of Dynamic Apex.

This works:

System.debug( Contact.FirstName );

This gives the "not accessible" error message:

System.debug( sobjectVariable.get( 'FirstName' ) );

From a permissions standpoint, both should have the exact same limitation within my package. In my case, I'm simply converting my existing working package from strongly-typed code to heavy use of dynamic apex.
Quick update, my actual error message is:

System.SObjectException: Contact.FirstName not accessible due to package restrictions

It happens during field access, not during a dynamic SOQL statement.
I guess our situations are slightly different because I am using visualforce as opposed to s-controls, but this is probably still the same packaging issue that we are running into. Hopefully someone with some more information will get on this soon.
I am having the same problem, with dynamic soql querys,

System.QueryException: PrefixXXX_OBJECTXXXX__c is not accessible in query due to package restrictions

If there any formal bug o planto fix this ? or some way to avoid this issue until then?
I was just informed that this is a known issue and the fix is a few weeks out. The work-around appears to be to avoid using packages with dynamic apex/SOQL until that fix is out.
I'm running into the same issue trying to perform a dynamic DML from a Visualforce page.  I get the error: Contact.HasOptedOutOfEmail not accessible due to package restrictions.  What's got me stumped is that I'm developing brand new code which is currently unpackaged.  Here are the relevant bits of code: 


List<String> EmailOptOut = new List<String>{'HasOptedOutOfEmail','Checkbox'};
List<String> CatalystNewsletter = new List<String>{'Catalyst_Newsletter__c','Checkbox'};
List<String> HFHCNewsletter = new List<String>{'HFHC_Newsletter__c','Checkbox'};
List<String> DoNotCall = new List<String>{'DoNotCall','Checkbox'};
List<String> IssueInterest = new List<String>{'Issue_Interest__c','MultiSelect'};
List<String> DoNotMail = new List<String>{'Do_Not_Mail__c','Checkbox'};

Map<String, list<String>> leadToContactFieldMap = new Map<String, list<String>>{
'HasOptedOutOfEmail' => EmailOptOut,
'Catalyst_Newsletter__c' => CatalystNewsletter,
'HFHC_Newsletter__c' => HFHCNewsletter,
'DoNotCall' => DoNotCall,
'Issue_Interest__c' => IssueInterest,
'Do_Not_Mail__c' => DoNotMail


for(String leadField : leadToContactFieldMap.keySet()) {
String[] contactFieldInfo = leadToContactFieldMap.get(leadField); String contactField = contactFieldInfo[contactFieldArrayName]; String contactFieldType = contactFieldInfo[contactFieldArrayType]; if (contactFieldType == 'Checkbox') { c.put(contactField, ld.get(leadField)); }

Any ideas?

I am running into the same issue.

Any Idea when salesforce is fixing this?
I understand that fixing this issue would take a while, may be until next release.
It would be greate that guys at salesforce.com write a post on the offical blog, of what things can not be packaged on winter09.
Best regards.
MG ConsultingMG Consulting
Hi All,

I think I figured out a workaround for this. Enable restricted API access for your package and give yourself read access to the standard object you were trying to access via dynamic apex from your package. For instance, I was trying to dynamically query Case from my pkg and was getting errors in my test code and after restricting my pkg's api access and checking off read on Case it works just fine.

It makes no sense because an unrestricted pkg should have more access then a restricted pkg so I still think the fact that you have to explicitly grant access is a little bazar.

Anyway, hopefully this helps some of you out.

Thanks Mike. This is helpful.

But somehow now my code is not getting the Custom Fields. This is strange. I am getting both Standard and Custom fields in my dev Org but when I package this - I get only standard fields.

I am using -

mapSObjectField_Contact = Schema.SObjectType.Contact.fields.getMap();

Any help here will be great!

Rakesh Aggarwal

Any other fix or solution for this? Please advice. This issue is a stopper for me.

Will this be fixed in the Spring 09 release and we can use Dynamic SOQL in a managed package ?

I read that now bind variables are supported in Dynamic SOQL, maybe they worked on this as well.

Can someone from Salesforce please respond.


I was getting this same "sf:INSUFFICIENT_ACCESS" error with an OLD package of mine (probably not touched since January 09). After reading through some threads like this, I removed the API restrictions on the managed package and at least I got a different error! So thumbs up to the recommendation about checking your package APi restrictions.