Apex Code Development You need to sign in to do that
Don't have an account?
JasonGabler SOQL Query produces unexpectedly empty List.
Here's a simple trigger intended to update one Contact lookup field (c.Affiliate_Admin__c) with an analogous Contact lookup field (Notification_Recipient__c) whenever the Contact is created or updated. The Notification_Recipient is found by looking at the Contact's Account record.
trigger Contact_setAffiliateAdmin on Contact (before insert, before update) {
for(Contact c: Trigger.new) {
if (c.AccountId != null) {
c.Affiliate_Admin__c = [SELECT Notification_Recipient__c from Account where Id=:c.AccountId].Notification_Recipient__c;
}
}
}
Occassionally this line produces the following error: "List has no rows for assignment to SObject"
Mt first thought was that the trigger was encountering Contact records that were not associated with an Account, and so my query produces and empty list (of Accounts) and cannot do the dereference for Notification_Recipient__c. However, when I run a reporting looking to find Contacts with AccountId = "", I find there are no such records.
If Notification_Recipient__c was null, there wouldbe no error message and Affiliate_Admin__c would just be set to null i the assignment, correct?
I'm out of ideas... do you have any? Some other way to verify Contacts with no accounts?
thanks,
jason
As you've got a null check for c.AccountId, I wouldn't expect the scenario of a contact without an account to be a problem. It has the feel of a race condition - like the account has been deleted in another transaction while the contact is being inserted, but I have no idea whether that would even be allowed by Salesforce.
Its better practice to store the results in a List and check if its empty, even if it seems impossible that it could be. It would also be better to pull all the accounts back in one go rather than each time through the loop, as a bulk change could cause the limit to
belowblow.Thanks for the reply, Bob. I had a similar cocern regarding a race of some sort. This other, racing workflow or trigger must be removing the Contact from the Account, which seems absurd to me. Even if I were to follow your advice about storing the result first (which is great advice), I believe it woud it would just mask the real bad behavior.
Any other thoughts would be greatly appreciated.
jason
It would indeed just mask the bad behaviour. Though you might take the view that as you can't change it, at least you don't have to hear about it ;)
You might want to dump out some information about the contact that caused the exception so that you can check if its associated account appears in the recycle bin or similar.
Do you carry out a lot of account merging? That seems a possible candidate for changing things underneath you.