>>Microsoft keeps changing the format, trying to force everyone to keep buying new versions every few years.
>
>Using COM-based automation allowed us to mitigate the import issue. For over 20 years it worked unchanged from within VFP and other win32 dev environments that could handle COM objects properly. I touch wood that it play on for another 20 years. But would not bet on this:)
>
>As far as I am concerned, I'll change my Excel management stuff to xlsgen when I can find the time to do the job?
>
>http://xlsgen.arstdesign.com/
>
>Xlsgen? Yep a hardcoded C++ based library that allows anyone including VFP coders to handle XLS import/export/massaging with zero de
>pendencies on MS, java or dotnet. A great work from an independent developer. You dislike independent developers? This tool has been on the market for well over 13 years. And remember that most of you are on the UT:)

As I said before, all my imports from Excel are one-time, i.e. conversions, not any kind of daily automated imports. So whatever I have to convert, I open with LibreOffice Calc, export as tab delimited, and then open with filetostr() and pass to my code. As for exports, it's exported to XL5, I think... dunno, it's somewhere in the framework, don't even remember where.

If I had to do regular imports, I'd sure go for XlsGen.