Re: Xlxs Parsing Issue

I, for one, would seriously consider doing the work in Excel, using, say, a VB script within one or the other spreadsheet. Let it open up a new Excel.Workbook object (perhaps a template with various named cell-ranges assigned for this purpose ...), and iterate through it to populate the data from one to the other. It is usually a good idea to use named cell-ranges in the source data, too, and I would gamble that your source spreadsheet is already doing this. (Code that refers to cells by their coordinates is fragile, not “future-proof.”)

While Perl does, as already mentioned, provide support-packages for dealing with this file format, “Excel is fully-programmable, too, and Excel knows herself best-of-all.” So, that’s how I would do it, have done it, and would frankly recommend doing it.

Replies are listed 'Best First'.
Re^2: Xlxs Parsing Issue by dasgar (Priest) on Nov 08, 2013 at 00:50 UTC
On one hand, I agree with you and I personally prefer to use Win32::OLE to control Excel when trying to manipulate Excel files when on a Windows system that has Excel installed. However, I would urge caution about leveraging macros, which is what I think that you're referring to when you mention "VB script". To make a long story short, apparently there was a situation at my job some time prior to when I started where a macros in an Excel file got infected by a virus and was deleting "random" files on our file server whenever that macros was run. I don't have all of the details on what happened there. Also, there's a reason that Microsoft's latest versions of Office has macros disabled by default. Not disagreeing with you on anything, but just wanted to pass on a word of caution.	[reply]
Re^3: Xlxs Parsing Issue by Anonymous Monk on Nov 08, 2013 at 00:55 UTC
That word of caution applies to any and every file on windows -- they're all attack vector -- every file is executable	[reply]