@Starz26: Thanks for the feedback. That is the first solution I thought of. However, now I've lost the benefit of having those three operations as part of one transaction. Or... is it one transaction per dml statement, and not necessarily per execute() call?

Here is what I "need to do" (and thanks for offering your insights!):

I have a custom Contact attribute called subscriptions__c. That attribute is a simple String. It's value is determined by the Contract and ContractContactRole associated with the Contact. I do need to take the CCR "role" value and place it in the Contact's subscriptions__c attribute. This is also dependent on the contract start date and end date.

So, my strategy is to create a Batch Apex class, whose execution I schedule via a Schedulable. My Batch Apex Class does the following:

start(): returns a QueryLocator via [SELECT Id, Subscriptions__c from Contact]

execute(): calls three methods, resetSubscriptions(), populateFooSubscriptions(), populateBarSubscriptions()

Here's what resetSubscriptions does:

private void resetSubscriptions() {

    List<Contact> contacts = [SELECT Id, subscriptions__c FROM Contact WHERE subscriptions__c != ''];
    for (Contact c : contacts) {
      c.subscriptions__c = '';
    }
    update contacts;
  }

 I'm taking this approach of just setting all subscriptions__c values to '' because that alleviates the need to calculate Contract expirations and so on. Instead, my intent is to reset them all to '' and then regenerate them all via populateFooSubscriptions() and populateBarSubscriptions().

The function resetRubscriptions() would typically affect about 6000 Contact records.

populateFooSubscriptions() looks like this (explanation after the code):

private void updateFooSubscriptions() {
    // Update Foo Subscribers with active contracts.
    // An active contract has a Role value of "Active Seat - Foo" (where Foo is the edition name)
    // and the contract's startDate and endDate surround the current date.
    List<ContractContactRole> activeCCRs = [SELECT Id, Role, Contract.startDate, Contract.endDate, Contact.subscriptions__c FROM ContractContactRole WHERE Role LIKE 'Foo%'];
    Map<ID, Contact> subscribers = new Map<ID, Contact>();
    for (ContractContactRole ccr : activeCCRs) {
      String editionName = extractEditionNameFromContractContactRole(ccr.Role);
      if (ccr.Contract.startDate <= Date.today() && ccr.Contract.endDate >= Date.today()) {
        if (ccr.Contact == null) {
          continue;
        } else if (subscribers.containsKey(ccr.Contact.Id)) {
          subscribers.get(ccr.Contact.Id).subscriptions__c = appendEditionName(subscribers.get(ccr.Contact.Id).subscriptions__c, editionName);
        } else if (ccr.Contact.subscriptions__c == null || !ccr.Contact.subscriptions__c.contains(editionName)) {
          ccr.Contact.subscriptions__c = appendEditionName(ccr.Contact.subscriptions__c, editionName);
          subscribers.put(ccr.Contact.Id, ccr.Contact);
        }
      }
    }
    List<Contact> uniqueSubscribers = subscribers.values();
    update uniqueSubscribers;
  }

 This function does the following:

- creates a List of ContractContactRole objects

- for every ContractContactRole, checks to see if it should populate the associated Contact's subscriptions__c attribute

- ensures that we've only got distinct Contact objects in the collection (via a Map)

- executes a DML update on those Contacts

This function affects about 500 Contact records.

Lastly, updateBarSubscriptions() is similar to updateFooSubscriptions() above, but it does the following:

- creates a List of Contract objects via [SELECT Id,startDate,endDate,product__c,subscription_type__c,enterprise_email_extensions__c, Account.Id, Account.parentId FROM Contract WHERE subscription_type__c LIKE '%Bar%' AND startDate <= today AND endDate >= today ORDER BY startDate];
- iterates over that list, and for every Contract, generates a list of Contacts via [SELECT Id, email, subscriptions__c FROM Contact WHERE accountId IN :accountIds]

- it then assigns a value to those Contact objects' subscriptions__c attribute, and adds the Contact to a Map that is outside the scope of the iteration drama

- after iterating over the Contracts, executes a DML update on the Contact objects.

This function tends to affect about 6000 Contact objects.

So that's 6000 Contact records that I modify via 'reset', and about 6500 that I modify via the other two functions.

My question is, is there a way I can "break this up" to avoid hitting the governor limit yet still be part of the same execute() call? Furthermore, what's the point of Batch Apex if we still have to adhere to this limit? I previously had this drama in a standard Apex class and it ran in under 60 seconds. With Batch Apex, which generates 328 batches, it takes over an hour.

If i have to split this up, I might as well not use Batch Apex!

I just did a quick look and from what I see these are 3 seperate transactions and should be placed in thier own batch.

I am not sure what yiou mean by this : "now I've lost the benefit of having those three operations as part of one transaction." as it does not appear that one transaction has anything to do with the other...I will look it over more in a bit to try and get a solid understanding.

The 10,000 DML is per transaction.

**Just in case: For all of these, do not call apex classes them from the batch, actually put all this code in the batch and use the main query in the start function. Just covering that base to ensure that you are not using the code as written below in it's own class**

I would simply put #1 in its own batch. You may need to reqork how your query is structured as I believe that you could potentially end up with the "Non specific query error"

For #2, again, seperate batch but I would limit the scope when calling the batch to say 10 records or something low. The reason for this is to ensure that you are keeping the dmls li

mited. If you limit the batch size, your for loop will only return the results for the 10 contracts and thus limit the data found per transaction

For #3, again seperate transaction, limiting the scope limits the number of DML's per transaction.

The key part here is that batch apex is designed to run against ONE query and perform manipulation of the data returned from / based on that query.

Simply putting additional, unrelated queries inside the execute block is not best practice. If you are performing additional Query / dml not based of of the initial query called in the batch then you probably should be doing that in its own batch class.

Also, unless one batch depends on another batch (handle that by scheduling or chaining) I do not see any benifit in doing it all in one class..