vshortt has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks and thank you for taking the time to read my questino and provide a little insight.

I have a very simplistic program that I am using to connect to a somewhat unknown database sytem called Rbase. They have been kind enough to proovide an ODBC connector for their system (called Ottero) so I have been attempting to use it with the DBI module to begin gleaning some basic info out of the tables.

I have used this same code, modified for Mysql connectivity and it works a treat, but when I use it to connect via the ottero ODBC driver, I receive "result too large" errors at a command prompt level run (although it does complete and supplis the table data), and the CGI interface simply dies completley at the connect() command and I either get a 500 error from the browser, no response at all. I have even placed 'trace' print commands at each line to see where it dies... it's at the connect() line.

Here is my simple code:

#!c:\perl\bin\perl.exe $|++; #sets $| for STDOUT use CGI qw(-debug); print "Content-type: text/plain\n\n"; use DBI; $dbase = "DBI:ODBC:rbase"; #Current Databa +se being used $dbh ||= DBI->connect($dbase); $dataObject = $dbh->prepare("SELECT * FROM product")or die "Can' +t prepare to verify parts $DBI::errstr"; $dataObject->execute()or print "Can't execute to verify parts $DBI +::errstr"; while (@tname = ($dataObject->fetchrow_array)) { print "@tname"; }

As you can see, this basic program is in no state to be made public, but in this simplest form, if should connect without issue.

again, thank you for your help in advance.

Replies are listed 'Best First'.
Re: Result too large using DBI::ODBC
by locked_user sundialsvc4 (Abbot) on May 09, 2012 at 18:44 UTC

    A quick Google of the message confirms that this problem is by no means peculiar to Perl.   It is an ODBC issue, and I would first raise the question with “them.”   If you have access to a low-level ODBC debugger/tracer tool, then this would be an excellent time to use it, and it might well be the most informative approach that you can try.

    Googling confirms quickly enough that these issues aren’t related to what you might initially suppose:   the query and/or the size of its result-set.   But it could, certainly, be related to some (at the moment, unknown to you...) series of interactions that the driver has with the server during the connection-time handshaking, and those, in my experience, could be absolutely anything.   A PostGres-based custom driver that I once dealt with, for example, actually made some very substantial queries against the system catalog at the beginning of every connection.   I have no idea what it was planning to do with whatever it was receiving, but it sent for the data nonetheless.   Therefore, I would first inquire with the authors of the driver.

    it could also be very informative to try other tools against that same driver.   What would Excel do?   MS-Access?   All of these “non-Perl” angles could be informative, and one of them just might hold the key.

      Solved!

      Thank you for the reply.

      After running an ODBC debugger and closely examining the ODBC logs, it appears that there is a part of 'their' driver that doesn't like mapped drives. Frankly, Neither do I.

      How I managed to not notice that this ODBC DSN was set up using a mapped drive is beyond me. I know better.. must have been a slip in sanity.

      Thank you for pointing me in the right direction!

      Regards

      Victor