>>>Take a look at:
>>>
>>>http://vfpx.codeplex.com/wikipage?title=XLSXWorkbook&referringTitle=Home
>>
>>Greg, thanks. I think this will do it.
>
>I think I've seen this before, even tried it out (if that's the one)... The reason I'm not using it is (primarily that I've managed to convince everyone who wants their data imported to export them tab delimited or CSV and not xls*, but also) that the format of the XLS* files will change with every other version, so any tool which takes binaries and tries to reproduce them will run into a situation when some users have the latest version and produce sheets which your tool still doesn't know of.
>
>I'm lucky here that I don't get those sheets in any kind of regular flow - I get them when I need to migrate a new customer's legacy data from various old systems, which somehow always have an utility to export the data into one of these formats (probably even dBase IV, but for those I didn't need an intermediate export), so it's a representative sample once, export for real the next time, done. No regular daily imports, which is very different.
>
>As long as you can get your sheet providers to stay with the current version until the tool you use can cope with the next version, you should be fine.

I think you're missing the point with XLSX format. It's a binary format only on the appearance, in fact it's an XML based format with a schema signature that provides compatibility for the future (and an ISO specification to go along, for that matter). As a data holder, it's more robust than CSV for the simple reason that CSV requires additional negotiation between producer and consumer agents that can not be formally expressed or embedded in the carrier file(s).