sObjects That Cannot Be Used Together in DML Operations
DML operations on certain sObjects can’t be mixed with other sObjects in the same transaction. This is because some sObjects affect the user’s access to records in the organization. These types of sObjects must be inserted or updated in a different transaction to prevent operations from happening with incorrect access level permissions. For example, you can’t update an account and a user role in a single transaction. However, there are no restrictions on delete DML operations.
- FieldPermissions
- Group
You can only insert and update a group in a transaction with other sObjects. Other DML operations are not allowed.
- GroupMember
You can only insert and update a group member in a transaction with other sObjects in Apex code saved using Salesforce.com API version 14.0 and earlier.
- ObjectPermissions
- PermissionSet
- PermissionSetAssignment
- QueueSObject
- ObjectTerritory2AssignmentRule
- ObjectTerritory2AssignmentRuleItem
- RuleTerritory2Association
- SetupEntityAccess
- Territory2
- Territory2Model
- UserTerritory2Association
- User
You can insert a user in a transaction with other sObjects in Apex code saved using Salesforce.com API version 14.0 and earlier.
You can insert a user in a transaction with other sObjects in Apex code saved using Salesforce.com API version 15.0 and later if UserRoleId is specified as null.
You can update a user in a transaction with other sObjects in Apex code saved using Salesforce.com API version 14.0 and earlier
You can update a user in a transaction with other sObjects in Apex code saved using Salesforce.com API version 15.0 and later if the following fields are not also updated:- UserRoleId
- IsActive
- ForecastEnabled
- IsPortalEnabled
- Username
- ProfileId
- UserRole
- UserTerritory
- Territory
- Custom settings in Apex code saved using Salesforce.com API version 17.0 and earlier.
If you are using a Visualforce page with a custom controller, you can only perform DML operations on a single type of sObject within a single request or action. However, you can perform DML operations on different types of sObjects in subsequent requests, for example, you can create an account with a save button, then create a user with a submit button.
- Create a method that performs a DML operation on one type of sObject.
- Create a second method that uses the future annotation to manipulate a second sObject type.
This process is demonstrated in the example in the next section.
Example: Using a Future Method to Perform Mixed DML Operations
This example shows how to perform mixed DML operations by using a future method to perform a DML operation on the User object.
public class MixedDMLFuture { public static void useFutureMethod() { // First DML operation Account a = new Account(Name='Acme'); insert a; // This next operation (insert a user with a role)
// can't be mixed with the previous insert unless
// it is within a future method.
// Call future method to insert a user with a role. Util.insertUserWithRole( 'mruiz@awcomputing.com', 'mruiz', 'mruiz@awcomputing.com', 'Ruiz'); } }
public class Util { @future
public static void insertUserWithRole( String uname, String al, String em, String lname) { Profile p = [SELECT Id FROM Profile WHERE Name='Standard User']; UserRole r = [SELECT Id FROM UserRole WHERE Name='COO']; // Create new user with a non-null user role ID User u = new User(alias = al, email=em, emailencodingkey='UTF-8', lastname=lname, languagelocalekey='en_US', localesidkey='en_US', profileid = p.Id, userroleid = r.Id, timezonesidkey='America/Los_Angeles', username=uname); insert u; } }
No comments:
Post a Comment