RE (tilly) 2: Bad codes for SQL

Unfortunately prepared queries really requires DBI.

What you do is "prepare" a query, get back a statement handle, then pass it the parameters when you "execute" it. If latency is low for inserting multiple rows this can can come close to the maximum theoretical throughput. But there is a lot of overhead to preparing a query with parameters.

Comment on RE (tilly) 2: Bad codes for SQL

Replies are listed 'Best First'.
RE: RE (tilly) 2: Bad codes for SQL by Jouke (Curate) on Aug 18, 2000 at 15:58 UTC
"unfortunately" you say...I'd say: why use anything else?? Why should anyone use Win32::ODBC when DBI is available? Jouke Visser, Perl 'Adept'	[reply]
RE: RE: RE (tilly) 2: Bad codes for SQL by KM (Priest) on Aug 18, 2000 at 17:50 UTC
It's simple, it's fairly reliable, if you are only to use it on Win32 boxes it is easy (no install problems, no need to worry about XS). Using it in the past has made a few projects easy, and more easily distributable. It was a design decision that fit best. A Honda may not be as nice as a Porche, but they both get you from here to there :) Cheers, KM	[reply]
RE (tilly) 4: Bad codes for SQL by tilly (Archbishop) on Aug 18, 2000 at 17:40 UTC
Because it makes it hard to just slip it into old scripts that someone else wrote with Win32::ODBC. Also there is some resistance to learning new modules.	[reply]