I noticed that in the Data Loader mapping file (.sdl) names of fields of target objects must have exact the same spelling as on target Org (mean case-sensitive). Data loader does not show any error or warning but values for fields with names in different case (UPPERCASE for instance) ignores (WHY?) by Data Loader.

The other curious thing is that when you extract data from the org you get csv file where field names are always in UPPERCASE (WHY?).

So, imagine that I need to extract data from one org, automatically generate mapping based on header of CSV-file (here is a problem) and load data to another org with the same data structure using Data Loader CLI.

Do anybody know how to force Data Loader to extract CVS with exact field names (no UPPERCASE) in header? Is it possible to force Data Loader CLI load field values even if names of fields in mapping file specified in different case?

  • It looks like issue with field names case sensitivity was already reported on github - github.com/forcedotcom/dataloader/issues/43 Jul 16, 2015 at 18:45
  • One of the contributors of Dataloader on github, answered in issue thread that it is fixed and will be released as a source code soon. Release of new version with mapping case-sensitivity fixed will be in this Fall. Jul 21, 2015 at 12:53

1 Answer 1


The Apex Data Loader isn't particularly user-friendly (although it is getting better as time goes on). This is because it was originally designed as an internal tool for salesforce.com employees to move data (e.g. for Premier Support to move or import data). It started out that some Premier Support customers found out about it and wanted it themselves, with the net result being that it was eventually released to the public.

It doesn't have many of the features of more advanced data loaders, such as dataload.io, Jitterbit, Relational Junction by Sesame Software, Dream Factory, Informatica Cloud, etc (standard disclaimer: I have never worked for any of these companies and do not endorse any particular software). Nor does it pretend to, as it is a free, open-source software piece provided by the company that the software works for with no guarantees of reliability or performance. If it were so fully featured that their partners were shot in the financial foot, that would look bad.

If you want to fix the problem, you can do so yourself by forking a copy from GitHub, patching it, and building it yourself. Some Java knowledge will be useful here. You're free to build whatever you want on top of it and use it for yourself, although you're not allowed to distribute it as if salesforce.com endorsed it, nor distribute it without retaining the license/copyright information.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .