Data Loader Java Heap Space Error

Exporting or inserting attachments using Apex Data Loader via the command line will often fail with an 'out of memory' error due to a lack of java heap space. This can fixed by expanding the heap size in the process.bat file in the bin folder using the -Xms and -Xmx switches:

..\_jvm\bin\java.exe -cp ..\DataLoader.jar -Xms32m -Xmx128m -Dsalesforce.config.dir=%1 com.salesforce.dataloader.process.ProcessRunner %PROCESS_OPTION%

When not specified, the heap size defaults to 1MB but will increase to 16MB as needed. The above code increases the allotted memory to 32MB and allows for expansion to 128MB if needed.

See this article by Brett Spell for more on setting heap sizes. Thanks also to Anna478 and Demand Chain Sysytems.

Reference external java beans with absolute path

I run a bunch of batch file exports from Salesforce calling Data Loader from the command line, with multiple process-conf.xml files defining various tasks. Originally I stored the SFDC credentials in each bean, then shifted the credentials to variables, still within the same xml file, using java.lang.String classes with constructor-arg properties:

Spring bean variables with data loader command line

If you use Apex Data Loader from the command line, you will know that changing usernames, passwords, and environments is a bit painful if you have more than one bean in your process-conf.xml file. Adding variables should be easy but getting the syntax right without an IDE is not. I couldn't find much help on the web so a Java guru colleague came through with the following fix.

Change encrypted password in data loader CLI

One of the processes I run regularly is a batch file calling Apex Data Loader to export a number of objects from my Salesforce org. I use these files to populate a fresh backup of the Salesforce data, and when my password changed recently I needed to generate a new encrypted string to use in the proces-conf.xml file. However, even though the encryption process is fairly simple, the documentation provided isn't clear.

Salesforce Date fields are really DateTime fields

Migrating data into Salesforce takes up a lot of my time, and I use Apex Data Loader to carry out most of the heavy work. Usually I test migrate into my client's sandbox and then migrate into their production instance. However, one recent client insisted that their own support team carry out the final migration into production. So I handed over the csv files and my migration notes, but they struck a number of errors with environmental differences, especially dates.