2

I have simple query in my apex class. It works 100% in all the developer orgs we tested.

List<Account> allAcc = new List<Account>([SELECT Id FROM Account WHERE Primary_Adviser__c =:FINALID]);

It works well in the Production's developer console and returns a value but it doesn't return any values on the managed package itself.

The Debug Log only shows fews lines:

33.0APEX_CODE,DEBUG;APEX_PROFILING,INFO;CALLOUT,INFO;DB,INFO;SYSTEM,DEBUG;VALIDATION,INFO;VISUALFORCE,INFO;WORKFLOW,INFO
21:58:43.606 (606337311)|ENTERING_MANAGED_PKG|ASFF
21:58:43.609 (609746129)|SOQL_EXECUTE_BEGIN|[8]|Aggregations:0|SELECT Id FROM Account WHERE Primary_Adviser__c = :tmpVar1
21:58:43.614 (614850395)|SOQL_EXECUTE_END|[8]|Rows:0

I already tried changing the code and everything with it and still no progress. Can anyone please share your ideas/experiences/solutions for this scenario? Thanks!

5

Do you perchance have a duplicate field now Primary_Adviser__c, one deployed in the Managed Package (now ASFF__Primary_Adviser__c), where it will of course be null and then one unmanaged already in the org? When you query in Dev console, you'll be querying the unamanaged field whereas the field will have been deployed with your managed package thus be prefixed with a namespace. It will be the managed version that is queried from within the managed package.

If this is the case, you have two options:

  1. Remove the unmanaged field from Production, populating ASFF__Primary_Adviser__c with its content before doing so
  2. Or, change the code in your Managed Package to refer to the field dynamically and then have that field removed from the package contents. Since you have already released the package, you will need to have Salesforce turn on the feature that allows you to delete managed components - which is a bit of messing about, but more likely the better solution.

The moral of the story is, take care with what components you pull into your managed packages with releases - always worth a check prior to installation on production.

| improve this answer | |
  • thanks for your answer. If we choose to use the number 2 answer which is refef the field dynamically, will it run as expected even if we will not remove the field from our package ? – Hope Oct 14 '15 at 2:25
  • Yes, you will need to remove the field from the package, but not from the DE org. That way, it can still function in tests etc. but won't be deployed in your target org. Of course, it would fail if Primary_Adviser__c didn't exist in your target org. – Phil Hawthorn Oct 14 '15 at 6:22
-1

Please check if your class is using 'with sharing' keyword, something like public with sharing className{} instead use public className if it is feasible for you.

With the use of 'with sharing' keyword, class runs in user context; without this keyword, it runs in system context.

Consider increasing the API version of the class if it is too low.

Only use namespace prefixes when referring to custom objects and fields in managed packages that have been installed to your organization from the AppExchange.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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