SObject row was retrieved via SOQL without querying the requested field on managed package

Question

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:

{!namespace__CustomObject__c.namespace__CustomField__c}

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:

<form  
    action="https://someurl.com/{!Object__c.Custom_Field__c}”
method="post" enctype="multipart/form-data">
    <input type="hidden" name="key" value="{!Object__c.Custom_Field2__c}” /> 
    //some other stuff
</form>

Answer 1

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

<!-- this is bad -->
{!Account.PackagedField__c}

<!-- 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.

Answer 2

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"/>