Re^2: Reading from Excel and writing to Oracle

DBD::Excel itself may not have changed much, but there may not be much to change (I don't use Excel so I don't know) . But it's just a shim between SpreadsheetParseExcel and SQL::Statement and DBI and all of those modules have changed. Unless you need to do manipulation of the spreadsheet or complex queries, it should be sufficient for this task. If you're reading from one database and writing to another, it makes sense to do it all in DBI. If DBD::Excel isn't suitable, then you can declare Excel as an ODBC DSN and use DBD::ODBC on it.

Comment on Re^2: Reading from Excel and writing to Oracle

Replies are listed 'Best First'.

Re^3: Reading from Excel and writing to Oracle
by Tux (Canon) on Aug 25, 2007 at 08:26 UTC

Well said. DBI-1.59 was released only yesterday! Spreadsheet::ParseExcel is also well maintained.

Same points are valid for all wrapper modules, including my Spreadsheet::Read. If Spreadsheet::ParseExcel or Spreadsheet::ReadSXC changes, the wrapper also changes.

DBD::Excel seems like a very valid choice, but still limits you to Excel only. It won't work on OpenOffice, but it will probably make a very clear and consice conversion program. (/me imagines a DBD::Spreadsheet in the future. Not that I have current plans, but it would be fun to experiment with that. :) Problem is that there is no Spreadsheet::Write (yet), so this DBD would be read-only.

I would personally NOT advice the use of DBD::ODBC on Excel for a plethora of reasons. I have just gone through the pain of using ODBC on windows to connect to several ODBC sources, and the number of locations where things can go (and will go) wrong is inmeasurable, ranging from non-matching buffer sizes to 32/64 bit mismatches and array fetches that don't. For the problem stated, I think that using ODBC is heading for the Yak-shaving path.

Enjoy, Have FUN! H.Merijn

[reply]


There's more than one way to do things
	PerlMonks