So, we uploaded the managed package and installed it in a new org (as the clients would) but when accessing a vf page we get the error

SObject row was retrieved via SOQL without querying the requested field: namespace__MyObject__c.namespace__CustomField__c

The problem is that on the developer org everything works fine and on that VF Page we are not actually referencing any value that was the result of a query.

Any idea why this is happening?

Note: We follow this and tried appending namespace__ as:


But then the error we were getting at the subscriber org started happening at the developer org.

I'm referencing the custom fields like this:

method="post" enctype="multipart/form-data">
    <input type="hidden" name="key" value="{!Object__c.Custom_Field2__c}” /> 
    //some other stuff
  • might be namespace issue
    – sfdc
    Jun 6, 2014 at 18:17
  • Must be, but not idea why or how to fix it @sf.dev
    – Jose
    Jun 6, 2014 at 18:20
  • You error message has only one underscore, not two, after namespace and prior to 'c'.
    – greenstork
    Jun 6, 2014 at 18:57
  • Just a typo @greenstork
    – Jose
    Jun 6, 2014 at 19:52

2 Answers 2


There's a glitch with Visualforce pages regarding namespaces. The workaround is to always use a Visualforce input or output element.

<!-- this is bad -->

<!-- this is good -->
<apex:outputField value="{!Account.PackagedField__c}" />

After installing the package in another org, you'll see that salesforce magically patches the reference:

<!-- after installation, in installed org -->
<apex:outputField value="{!Account.namespace__PackagedField__c}" />

I uncovered this glitch on a project I was working for between 2012 and early this year. As far as I know, it's still not listed on Known Issues, nor does there appear to be timeline to fix this glitch. Note also that it doesn't "always" happen, but you should nevertheless always use this design pattern to avoid the problem.

Edit: Also, I recall that this problem would occasionally cause the managed package upload to fail and/or the install to fail with nothing more than a generic Internal Server Error with the usual numbered error code.

  • wow, ok. And what about if I can't use an <apex:outputField>? See update on question.
    – Jose
    Jun 6, 2014 at 19:50
  • I'm curious, would an <apex:variable>do the trick?
    – Jose
    Jun 6, 2014 at 20:07
  • Awesome!!! Just tried and worked with an <apex:variable>. Looks like as long as you have the {!Object__c.customField__c} reference inside an <apex> component you are safe.
    – Jose
    Jun 6, 2014 at 21:13
  • 1
    @Jose Any apex element works, including input, outputText, outputField, etc, as long as it is a type of element that has a "value" attribute that you can leverage.
    – sfdcfox
    Jun 6, 2014 at 21:18

I have suffered this error in the past as well, and we followed the same approach as sfdcfox.

In our Visualforce pages, we added a list of outputfields linked to the related sObject fields, and set rendered attribute to false to avoid displaying them:

<apex:outputField value="{!MyCustomObject__c.MyCustomField__c}" rendered="false"/>
  • 1
    That seems to be an approach that will slow things down. Why not use the standard controller methods for getting fields addFields(List<String>)? salesforce.com/us/developer/docs/pages/Content/… Jun 11, 2014 at 17:48
  • Thanks a lot, David. Indeed, this is the approach we followed in the past, but I really like your alternative and will start using it from now on. Jun 12, 2014 at 10:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .