This example is where the db and rails app are separate (since we are passing in the host). But, since the rails app has access to the db server, we can access it via the rails app server.

As far as obfuscating sensitive data, things would be more simple in smaller datasets, but when you're dealing with millions of records, it can quickly get complicated and take a long time. Some of the issues with large data would be 

I know that we're sometimes in situations where we get to the point of saying, "but I need the production data". At that point, I would probably do a "hotfix" to add more logging in the area of the application and see what makes this particular org/company/user so unique. From there, you should, hopefully, be able to replicate it in your staging environment. If, you're seeing the same issues, then try to replicate it locally. If you're still unable to replicate the issue locally, then you could pull the staging database where the issue is being experienced. If pulling and loading the data to my local environment doesn't replicate the issue then there could be a difference in the environments (at an infrastructure level or some kind of environment flag within the code).

So, while it is kind of avoiding the question, I think that we shouldn't ever pull the production database (regardless of obfuscation or not).

  Luke Scott I would make a Ruby class which took in the results of a questionnaire and format it in a way that you're wanting the CSV to look. So, you'd basically make an array with the first item in the array being an array of all of the headers. Then you'd loop through each response and put their response in the appropriate position in the array. From there, you can generate the CSV response and send a file to the client.

  Tom Murdoch  If a questionnaire has already received responses, then I would not recommend altering the questionnaire. I've seen this before and it caused so many problems where the first several responses has the old questionnaire in mind but no longer valid. While, as developers of the questionnaire feature, we would know how to navigate this "safely", but end users will always surprise you with what they'd do. The safest thing would be to recall a questionnaire and generate a copy of an existing one to then modify.

Typically, when everything looks correct and I still cannot explain the problem, it is usually because of Spring. Did you just add the account number field or has it been there? Is it a column in the database?