+ Start a Discussion
Ken KoellnerKen Koellner 

MIXED DML error and pricebookentry

I have some batchable apex, in the execute() method, udpates are done to pricebookentry.

 

I'm getting a weird mixed DML error.  Originally I had pricebookentry and a custom table updated in the execute() but to be safe, I took out the other update.  Now the execute() is issueing exactly one DML to pricebookentry for a few hundred rows.  I still get the mixed dml error.  Not sure how I could get a mixed dml error when there is exactly one DML issued.

 

09:23:22.107 (92107648000)|EXCEPTION_THROWN|[68]|System.DmlException: Update failed. First exception on row 0 with id 01u40000002CKwBAAW; first error: MIXED_DML_OPERATION, DML operation on setup object is not permitted after you have updated a non-setup object (or vice versa): CustomFieldDefinition, original object: PricebookEntry: []

 

The message doesn't make much sense as it says there's an attempt to update "CustomFieldDefinition".  That sounds like metadata, not data.  And as I mentioned, there is exactly one dml, to pricebookentry.

 

Yes, I did open a case with Tech Support.   I updated the logic to a single DML this morning and added that to the case, still waiting on a response after that update.

 

I thought I'd post here anyway in case anyone else has experienced this anomoly.

firechimpfirechimp

Hi Ken,

As I am sure you are aware Mixed DML occures when carrying out a DML opperation on both a serup object (most salesforce standard CRM objects and things like User and custom settings) and a custom object.

 

My guess would be that even though you may only be updating the pricebookentry in your bach apex. There may be other events within the same transaction (such as a trigger) that is updating a custom field somewhere. And therefore causing a Mixed DML opperation to take place.

 

I would suggest running the update from execute anonymous in the developer console, and checking the debug logs to see if any triggers or workflows etc... are been called after the update of these records.

 

Hope this helps!

 

Ken KoellnerKen Koellner

I do know what causes MIXED DML exception according to the documentation.

 

There are no triggers fired, I checked the Apex log on the batch that failed.

 

The DML is against pricebookentry.  You can't define a trigger against pricebookentry. 

 

At one point, I had a trigger on a custom objec that then updated pricebookentry in turn.  But I changed the design and completely removed that custom object from the picture.

 

I've looked through the log several times, there is no trigger fired and no other DML shown in the log.

 

Starz26Starz26

I am facing this same situation.

 

I have not found the cause.

 

If I update a single record it works fine. but when I change it to update a list of records it errors out.

 

 

It was working fine until yesterday and then bam, no longer can update the pbe in batched

Ken KoellnerKen Koellner

I worked with SF Tech Support.  Our issue was caused the the logic SF uses to asyncronously update roll-up summary fields.  That interfered with the DML to pricebookentry.

 

I got it down to a single case of one update to one row in pricebookentry.  If did a single DML to that row from apex, it hit the error.  Interestingly, if you updated the same row with the page layout, it didn't hit the error.

 

SF Tech Support said they acknowledge it as an isuse and are working on a fix but don't have an ETA yet.

 

-Ken

 

Starz26Starz26

Ken Koellner wrote:

I worked with SF Tech Support.  Our issue was caused the the logic SF uses to asyncronously update roll-up summary fields.  That interfered with the DML to pricebookentry.

 

I got it down to a single case of one update to one row in pricebookentry.  If did a single DML to that row from apex, it hit the error.  Interestingly, if you updated the same row with the page layout, it didn't hit the error.

 

SF Tech Support said they acknowledge it as an isuse and are working on a fix but don't have an ETA yet.

 

-Ken

 


This was the case for me as well. It was a roll up summary field on the account based on opportunities. (not even pricebooks). The field had been deleted but was not deleted from the deleted fields. So it was still there but unseen.

 

What a PITA

Ken KoellnerKen Koellner

Starz26 wrote:

 


This was the case for me as well. It was a roll up summary field on the account based on opportunities. (not even pricebooks). The field had been deleted but was not deleted from the deleted fields. So it was still there but unseen.

 

What a PITA


I would think then the easy workaround would be to remove the field from the deleted list.

 

 

We've found that we have hit the problem rarely so it hasn't been a show-stopper.  We have a few to a custom table that takes prices off our back-end system.  That table then updates PBE from a trigger.  Only a few times, that update has failed.  We worked around it by going to the product and manually editing the prices on the PBEs.

 

Without releasing a modified of our trigger code, we can't get the customer staging table to reflect the correct price as the trigger will always fire, but at least we can get the correct price in the PBE.

 

-Ken

 

Starz26Starz26

Ken Koellner wrote:

Starz26 wrote:

 


This was the case for me as well. It was a roll up summary field on the account based on opportunities. (not even pricebooks). The field had been deleted but was not deleted from the deleted fields. So it was still there but unseen.

 

What a PITA


I would think then the easy workaround would be to remove the field from the deleted list.

 

 

We've found that we have hit the problem rarely so it hasn't been a show-stopper.  We have a few to a custom table that takes prices off our back-end system.  That table then updates PBE from a trigger.  Only a few times, that update has failed.  We worked around it by going to the product and manually editing the prices on the PBEs.

 

Without releasing a modified of our trigger code, we can't get the customer staging table to reflect the correct price as the trigger will always fire, but at least we can get the correct price in the PBE.

 

-Ken

 


You would think it would have been an easy fix....BUT in trying to find the issue:

 

1. Narrowed the dat and time it began down.

2. Began deleting stuff to see if it would solve it.

3. We had requirements for the things being deleted

4. Once all items modified after that time were deleted it was still happening. (did not consider recycle bin)

 

Making the issue worse is that we could not deploy any code to our production org to debug as our test classes were now failing or no longer over 75% coverage. Could not deploy fixes to account for the issue to bring up the coverage until the issue was resolved. It was a catch 22...

 

On a whim, we began deleting the fields from the recycle bin and then everything worked again.....

 

Thank you so much for posting this thread, it saved a lot of headache....