1

When I do a soql query with --format:csv, and I view the results file in excel it seems that all entries are padded with spaces to match the column header width.

This is not a huge problem but it's inconvenient -- for example it caused my VLOOKUP to fail and since the spaces were "invisible" it was hard to debug.

Is this a feature or a bug? I've not encountered this when using Data Loader or Workbench.

Improve this question
5
  • This sounds like a problem with Excel, not salesforce.com. I just tried it out in my dev org and it works as expected.
    – sfdcfox ♦
    Commented Apr 5, 2016 at 18:17
  • The spaces are in the csv file whether I view it in text editor or excel. If you are interested I can send you examples offline. Also you will only see this if the column names are wider than the entries.
    – PaulM
    Commented Apr 5, 2016 at 18:19
  • Oh. Let me try that out when I get to my desk.
    – sfdcfox ♦
    Commented Apr 5, 2016 at 18:21
  • I'm able to duplicate the behavior. I also found the source code-- let me see if I can track down what's happening, and I can log a bug.
    – sfdcfox ♦
    Commented Apr 5, 2016 at 18:39
  • Looks like force/display.go lines 362-365 are responsible for this, but there's not a lot of comments to go on, and Go isn't a native language I know. If you're not already familiar, you can see the source at github.com/heroku/force.
    – sfdcfox ♦
    Commented Apr 5, 2016 at 19:03

1 Answer 1

Reset to default
1

I'm not sure if this is a bug or a feature, but regardless, I've filed an issue on your behalf.

In summary, assuming this is a bug, it's because the field values are being padded by a minimum length specified in the source code (force/display.go, lines 362-365), which I fixed by specifying a minimum length of 0 in my patch. It looks like I'll need to tweak it to allow "<nil>" values to be filtered out, too.

I was able to quickly patch this by changing just a few lines of code, but it seems that building a new version broke the OAuth login feature (possibly because I'm going to the wrong URL or something?) If you're interested, I can create a fork that includes the tweaks when I get time.

Edit:

@dcarroll says:

Right, ok, I've seen this. The original code tried to format the output nicely for the screen, hence, taking the longest field in the column, even it was the header, and use that to pad the output. I may have a fix for this, so I'll take a look.

So, the original function was to output nice, evenly matched lines (same as omitting --format:csv) for human consumption, and was probably left in there as a result. Looks like they'll get this fixed up for you, given time.

Improve this answer
2
  • Thanks a lot for looking into this, appreciate that. Because it differs from what dataload does, on that basis I think we can call it a bug.
    – PaulM
    Commented Apr 5, 2016 at 21:20
  • @PaulM I already got a response from a Heroku maintainer. They said they'll look in to it (be sure to follow the issue). I also found other differences as well, such as the fact that it automatically sorts your field names in alphabetical order instead of trying to parse the data directly (e.g. like the data loader), and blank fields appear as <nil> (which I also patched locally). I've also learned basic Go today. Yay, me!
    – sfdcfox ♦
    Commented Apr 5, 2016 at 21:22

You must log in to answer this question.

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