Clarification on Class::DBI wackiness

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

I am trying to set up an object with the aid of Class::DBI (actually Class::DBI::Sybase) All classes have been set up according to the documentation and I wrote a quick program to verify C::D behavior. The original test program ran retrieve_all() which was successful. However when I run a search() based on the PK an error is returned "sth_to_objects needs a statement handle".

Looking under the hood we find that indeed $sth is not valued, but oddly enough when sth_to_objects() is called (from within C::D itself) $sth is not even passed.

Obviously it must be something that I am doing wrong if there is plenty documentation on how to use the module, but nothing on the strange behavior experience by this humble monk.

Any advice?

Code and results...

The base class...

package user::user;

use base 'Class::DBI::Sybase';

user::user->set_db('Main', 'DBI:Sybase:database=YYYYYY;server=127.0.0.
+1;textsize=4550', 'xxxxxxxx', 'xxxxxxxx');

__PACKAGE__->table('users');
__PACKAGE__->columns(All => 'recnum', 'firstname', 'lastname', 'email'
+);

1;
[download]

The test program

#!/usr/bin/perl -w
use strict;
use user::user;
use Data::Dumper;

my @cols = user::user->columns;
print "COLUMNS:\n";
print "$_\n" foreach @cols;
print "\n\nAnd now the table data...\n";
my @obj = user::user->search(recnum =>1);
print "$_\n" foreach @obj;
[download]

The results

COLUMNS:
lastname
firstname
email
recnum


And now the table data...
sth_to_objects needs a statement handle at ./cdbi_tst.pl line 38
[download]

Thanks in advance

Comment on Clarification on Class::DBI wackiness Select or Download Code

Replies are listed 'Best First'.
Re: Clarification on Class::DBI wackiness by Joost (Canon) on Aug 03, 2005 at 16:11 UTC
IIRC, the set_db method has been deprecated. You could try using `__PACKAGE__->connection( ... )` instead. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply] [d/l]
Re^2: Clarification on Class::DBI wackiness by spork (Monk) on Aug 03, 2005 at 16:21 UTC
Thanks for the advice. I made the change to using connection(), but still get the same results.	[reply]
Re^3: Clarification on Class::DBI wackiness by Joost (Canon) on Aug 03, 2005 at 16:26 UTC
Hmm.. Looks to me that either the connection fails, or it's a bug in Class::DBI::Sybase. I don't have Sybase installed, but it looks like this code is correct. Maybe you can try it with another DB backend to see if that works. Did "make test" succeed when installing Class::DBI::Sybase? "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re: Clarification on Class::DBI wackiness by cees (Curate) on Aug 03, 2005 at 16:57 UTC
Try and use `set_up_table` instead of `table` and `columns` to configure your CDBI class to see if that makes a difference. `__PACKAGE__->set_up_table('users');` [download] `set_up_table` will read all the table information (like column names and primary keys and more) directly from the DB and setup your CDBI class for you.	[reply] [d/l] [select]
Re^2: Clarification on Class::DBI wackiness by spork (Monk) on Aug 03, 2005 at 17:37 UTC
Good tip. However set_up_table() returned all of the column names (original post represented a subset of the table columns) but still presented the "statement handle" error message when running search(). I'm stumped as to why retrieve_all() is successful while search is not coming from the same base class.	[reply]
Re^3: Clarification on Class::DBI wackiness by cees (Curate) on Aug 03, 2005 at 18:19 UTC
Are you sure it is not something else in your code that is causing this. The code you provide above looks like it should work fine. But your error message mentions the error occurs on line 35 of your test file. This tells me you have a bunch of other stuff in your test file. Strip your code down to bare minimum and test it again. Also, test your code out using SQLite instead of Sybase. This may give you a hint as to what is going wrong as well. If the same error happens again, then we know it isn't the Sybase module causing the problem, and most likely it is with your code.	[reply]