in reply to Most efficient MS SQL connection

banesong:

I wouldn't worry about it until database communications become a significant fraction of the time your application consumes. If communications takes 1% of the time, then improving communications speed by 90% will still make less than a 1% change.

Go after the big payoffs.

If your db communications *is* a signification fraction, then try other communication methods, such as DBD::Sybase and see which ones give you the best payoff.

...roboticus

Replies are listed 'Best First'.
Re^2: Most efficient MS SQL connection
by banesong (Acolyte) on Mar 02, 2010 at 17:14 UTC
    Thanks - I will say that DB communication is a significant portion of the time (aside from the few reports that need massive hash table manipulation, which is a whole other problem). I will look and see if DBD::Sybase will work any better.

      How did you ascertain that DB communication is a significant portion of the time? That is not my experience with DBD::ODBC and MS SQL Server with two exceptions which are a) when retrieving very large result-sets (and this could be improved by using array binding in DBD::ODBC but I've never had the impetus to do it myself) and b) when using dynamic or server-side cursors.

      I'd be most interested in your usage case if it really demonstrates a high proportion of the time in DB communication.

      Unlike some other people who claim using ODBC slows everything down (their usual reason is based on ODBC adds another layer over the TDS protocol and hence it must be slower) I've seldom seen an actual real life case with numbers that categorically proves adding ODBC makes a signifcant difference.