[SalesForce] Database Class Methods

These methods give you additional options if you want to something other than the default behaviour the DML Statements give, such as...

• allowFieldTruncation

  Specifies the truncation behavior of large strings.

• assignmentRuleHeader

  Specifies the assignment rule to be used when creating a case or lead.

• emailHeader

  Specifies additional information regarding the automatic email that gets sent when an events occurs.

• localeOptions

  Specifies the language of any labels that are returned by Apex.

• optAllOrNone

  Specifies whether the operation allows for partial success.

So you have three options

• Use the default DML statements (no control)
• Use the Database methods e.g. Database.insert(List records, Boolean allOrNone)
• Use the Database methods e.g. Database.insert(LIst records, DMLOptions options)

Depending on the options you want to control. You also get additional information returned from these methods that allow you to inspect the results of the operation at an individual record level, for example SaveResult. Here is the sample from the documentation around the use of the allOrNone option...

// Create two accounts, one of which is missing a required field
Account[] accts = new List<Account>{
    new Account(Name='Account1'),
    new Account()};
Database.SaveResult[] srList = Database.insert(accts, false);

// Iterate through each returned result
for (Database.SaveResult sr : srList) {
    if (sr.isSuccess()) {
        // Operation was successful, so get the ID of the record that was processed
        System.debug('Successfully inserted account. Account ID: ' + sr.getId());
    }
    else {
        // Operation failed, so get all errors                
        for(Database.Error err : sr.getErrors()) {
            System.debug('The following error has occurred.');                    
            System.debug(err.getStatusCode() + ': ' + err.getMessage());
            System.debug('Account fields that affected this error: ' + err.getFields());
        }
    }
}

We can't control commits, because there's too much system logic that depends on us not being able to commit directly to the database. For example, if we performed a commit and the transaction later failed, we would have committed data we can't roll back, but the remaining data hasn't been finalized, so we are left with a database in a possibly corrupt state; we then have to explicitly undo whatever we did up to the commit point.

Also, things like sending emails also commit records to the database. If we committed an email that contained some data, then the records themselves failed to save to the database, the email would be sent in error. There's simply too many complications with allowing users direct access to the database. This is why we have a database application layer exposed to us-- Salesforce abstracts the Oracle database away from us, so we can focus on business needs (CRM), rather than managing a database.

I could mention a ton of reasons why explicit commits would be a bad idea. It's hard enough to get commits "just right" when we're given our own databases (e.g. MySQL), without trying to predict how our commits might affect the underlying system logic. I do find myself wishing there was a way to side-commit records that should survive a failed transaction, but that's not a feature we have right now.