Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
share|improve this question
might be namespace issue – sfdc Jun 6 '14 at 18:17
Must be, but not idea why or how to fix it – Jose Jun 6 '14 at 18:20
You error message has only one underscore, not two, after namespace and prior to 'c'. – greenstork Jun 6 '14 at 18:57
Just a typo @greenstork – Jose Jun 6 '14 at 19:52
up vote 10 down vote accepted

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.

share|improve this answer
wow, ok. And what about if I can't use an <apex:outputField>? See update on question. – Jose Jun 6 '14 at 19:50
I'm curious, would an <apex:variable>do the trick? – Jose Jun 6 '14 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 '14 at 21:13
@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 '14 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"/>
share|improve this answer
That seems to be an approach that will slow things down. Why not use the standard controller methods for getting fields addFields(List<String>)?… – DavidSchach Jun 11 '14 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. – Jesus Arcas FinancialForce Jun 12 '14 at 10:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.