My experience is that MS products can't produce a useful CSV file even when you try to export manually from a document created in the product itself (Excel springs to mind). So, I'd skip the OLE\Excel steps and go straight for one of the pure Perl solutions mentioned. They are much easier, more controllable, and have a support community... Also, it might be helpful for us to see an example record of the type of data you're trying to CSV. | [reply] |
Could you clarify what you mean by can't produce a
useful CSV file?
My understanding and experience is that Excel generally
does a reliable CSV export. Here are the limitations and
issues that I know about. It cannot successfully
export structure that requires metadata which does not fit
in CSV format. (Hardly Excel's fault.) Many people do not
know how to parse CSV (split does not cut it, and the
interface to Text::CSV makes it impossible to
produce a reliable solution). (Again not Excel's fault.)
And several years ago they had a bug where positive floating
point numbers expressed in scientific notation were not
recognizable as being numbers by most other spreadsheets
(or Access IIRC). That was their fault, but has long been
fixed. And Excel, like most Microsoft products, uses
pre-emptive locking, which I find rather irritating and
inconvenient. (Not to mention a source of significant
trouble from time to time.)
Are there any other issues that I should be aware of?
| [reply] |
Ultimately I guess my Excel issues probably concern a more global desire for predictability of CSV format across products, which will probably seem mundane to you. Not that MS is the only player I have run into with these issues in the not-daily experiences I've had with this.
The Excel '97 on my laptop will export everything separated by a comma, unless there's a comma within the field (cell), whereupon it exports that cell (and only that cell) with double quote delimiters. It also offers me no controls to set preferences for this export type.
OTOH, my memory of it is that MS's FoxPro products seem to prefer to use double quote delimiters on all fields, Outlook exports with double quotes on all fields, but Outlook Express seems to export with commas only, just as examples. go figure. The other side of this is for me has been that over the years, various products I would use to import a file expected a CSV file to be in one or another structure (double quotes, no quotes, etc.) StarOffice products offers chooices on all the characteristics of these exports, which I of course admire and wish other products did the same.
| [reply] |
I am sorry for scaring you. I did not intend to. You have
a reasonable question, asked in a good way. What bothered
me was the quality of the responses that you got. I hold
answerers to a higher standard than questioners.
As for your more specific question, there are two possible
answers.
One is to use the format_csv function that I
gave you, and write a loop where you walk through your data,
fetch it into Perl, and then write the file yourself. I
would generally suggest doing that, my experience is that it
is easier to pull data into Perl and manipulate it in Perl
than it is to drive an external application.
The other is to get the Excel approach working. Not having
it available at the moment, I cannot test it. But I can
tell you that the error message will not generally be put
into $!. Instead you will need to call
Win32::OLE::LastError() to get the error message. No
promises, but the odds are pretty good that if you check
that you will get useful feedback. | [reply] |
Hey Toni, don't worry about it :-) It may be hard to tell, be we are all on your side.
With that said, though - I haven't played with OLE in about a year, so I can't tell you anything off the top...
Thanks for coming back to us :-D If no one has any solutions in the next several posts, I'll check it out when I get home and see if I can help. | [reply] |