Database Methods and Partial Success in Apex

A plain insert is all-or-nothing: if one record in 200 fails a validation rule, all 200 are rolled back and an exception is thrown. That's right for a single business operation, but wrong for a data load where you want the 199 good records saved and the bad one reported. The Database class methods give you that choice.

DML statement vs Database method

With allOrNone = true (the default if you omit it), Database methods behave like the statements.

Partial success with SaveResult

List<Contact> rows = new List<Contact>{
    new Contact(LastName = 'Verma', Email = 'asha@acme.example'),
    new Contact(FirstName = 'Missing'),                                  // no LastName
    new Contact(LastName = 'Kumar', Email = 'not an email'),             // invalid email
    new Contact(LastName = 'Rao')
};

List<Database.SaveResult> results = Database.insert(rows, false);

Integer ok = 0;
for (Integer i = 0; i < results.size(); i++) {
    Database.SaveResult sr = results[i];
    if (sr.isSuccess()) {
        ok++;
    } else {
        for (Database.Error err : sr.getErrors()) {
            System.debug('Row ' + i + ' failed: ' + err.getStatusCode() + ' – ' + err.getMessage() + ' ' + err.getFields());
        }
    }
}
System.debug(ok + ' of ' + rows.size() + ' saved');
System.debug('In the database: ' + [SELECT COUNT() FROM Contact]);

Row 1 failed: REQUIRED_FIELD_MISSING – Required fields are missing: [LastName] (LastName)
Row 2 failed: INVALID_EMAIL_ADDRESS – Email: invalid email address: not an email (Email)
2 of 4 saved
In the database: 2

Results come back in the same order as the input list, so results[i] belongs to rows[i]. That's how you report which source row failed – essential for imports, where users need to fix and resend specific lines.

A reusable pattern: collect failures

// DmlResultReport.cls
public with sharing class DmlResultReport {
    public Integer succeeded = 0;
    public List<String> failures = new List<String>();

    public DmlResultReport(List<SObject> records, List<Database.SaveResult> results, Schema.SObjectField labelField) {
        for (Integer i = 0; i < results.size(); i++) {
            if (results[i].isSuccess()) {
                succeeded++;
                continue;
            }
            List<String> messages = new List<String>();
            for (Database.Error e : results[i].getErrors()) messages.add(e.getMessage());
            failures.add(records[i].get(labelField) + ': ' + String.join(messages, '; '));
        }
    }
}

List<Account> load = new List<Account>{
    new Account(Name = 'Acme Corp', Website = 'acme.example'),
    new Account(Website = 'no-name.example'),                    // Name is required
    new Account(Name = 'Globex', Website = 'globex.example')
};
DmlResultReport report = new DmlResultReport(load, Database.insert(load, false), Account.Website);
System.debug('Saved: ' + report.succeeded);
for (String f : report.failures) System.debug('Failed: ' + f);

Saved: 2
Failed: no-name.example: Required fields are missing: [Name]

DMLOptions

Database.DMLOptions changes how a save behaves – truncating long text instead of failing, running assignment rules, or allowing saves that duplicate rules would block:

Database.DMLOptions opts = new Database.DMLOptions();
opts.allowFieldTruncation = true;                    // cut long text to fit instead of failing
opts.optAllOrNone = false;

Account longName = new Account(Name = 'X'.repeat(300));
Database.SaveResult sr = Database.insert(longName, opts);
System.debug('Saved with truncation: ' + sr.isSuccess());
System.debug('Stored length: ' + [SELECT Name FROM Account WHERE Id = :sr.getId()].Name.length());

// other common options
// opts.assignmentRuleHeader.useDefaultRule = true;            // Leads and Cases
// opts.duplicateRuleHeader.allowSave = true;                  // bypass "alert" duplicate rules
// opts.emailHeader.triggerUserEmail = true;                   // send standard emails (e.g. case comments)

Saved with truncation: true
Stored length: 255

Saving in user mode

Apex runs in system mode by default: object and field permissions aren't checked. When code acts on behalf of a user – an LWC controller, a REST endpoint – you usually want the user's permissions enforced. Add as user to a DML statement, or pass AccessLevel.USER_MODE to a Database method:

insert as user new Account(Name = 'Saved with the user\'s permissions');

List<Database.SaveResult> res = Database.insert(
    new List<Account>{ new Account(Name = 'Also user mode') }, false, AccessLevel.USER_MODE);
System.debug('User-mode insert ok: ' + res[0].isSuccess());
System.debug('Accounts: ' + [SELECT COUNT() FROM Account WITH USER_MODE]);

User-mode insert ok: true
Accounts: 2

If the user lacks create access to the object or edit access to a field you set, a user-mode save fails with a clear error instead of silently writing data they shouldn't be able to write. The security lesson covers this in depth.

Practice

Summary