CSV, as a file format, assumes one “table” of data; in Excel terms that’s one sheet of a workbook. While it’s just plain text, and you can interpret it any way you want, the “standard” CSV format does not support what your supervisor is thinking.
You can fudge what you want a couple of ways:
-
Use a different file for each sheet, with related but distinct names, like “Book1_Sheet1”, “Book1_Sheet2” etc. You can then find groups of related files by the text before the first underscore. This is the easiest to implement, but requires users to schlep around multiple files per logical “workbook”, and if one gets lost in the shuffle you’ve lost that data.
-
Do the above, and also “zip” the files into a single archive you can move around. You keep the pure CSV advantage of the above option, plus the convenience of having one file to move instead of several, but the downside of having to zip/unzip the archive to get to the actual files. To ease the pain, if you’re in .NET 4.5 you have access to a built-in ZipFile implementation, and if you are not you can use the open-source DotNetZip or SharpZipLib, any of which will allow you to programmatically create and consume standard Windows ZIP files. You can also use the nearly universal .tar.gz (aka .tgz) combination, but your users will need either your program or a third-party compression tool like 7Zip or WinRAR to create the archive from a set of exported CSVs.
-
Implement a quasi-CSV format where a blank line (containing only a newline) acts as a “tab separator”, and your parser would expect a new line of column headers followed by data rows in the new configuration. This variant of standard CSV may not readable by other consumers of CSVs as it doesn’t adhere to the expected file format, and as such I would recommend you don’t use the “.csv” extension as it will confuse and frustrate users expecting to be able to open it in other applications like spreadsheets.