>>>>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).

I know, it's a zipped set of folders/files in xml format, which should be future compatible, and it's pretty much what ODF did for years before that. However, this is Microsoft, and there's now even more space inside those xml files to introduce additional attributes etc to make any tool miss some features. At least reading what's inside should stay compatible for a while, as the Redmondlians usually don't remove features, they let them rot and add new ones. Writing would be a different matter - I've seen .nnnx files which look almost usable when written by outside tools and opened by an Office app. Luckily, for the purpose of this thread, we don't need any of extra features, just plain data.

The ISO definition of the .nnnx standard is almost comical, I've read some critiques of this 'standard' and it's mostly "the docx format is whatever Word outputs".