On Wed, 2004-05-19 at 18:53, Dave Boodman wrote:
> PK wasn't the problem. If you don't define it, it uses the first col.
And that is the correct primary key for this table?
> The return from the ->search looks like
>
> $VAR1 = \bless( {
> 'sysid' => '158'
> }, 'Lib::Systems' );
> $VAR1 = \bless( {
> 'sysid' => '1065'
> }, 'Lib::Systems' );
> $VAR1 = \bless( {
> 'sysid' => '1066'
> }, 'Lib::Systems' );
So what's wrong with that list of objects? Should there be more?
> Just for kicks I tried the ->retrieve_all and then filtered out the returns
> for the rows I wanted and that didn't work either.
Because the ones you wanted were not in the list?
> So we know 2 things:
>
> 1. Something about using the Class::DBI wrapper functions isn't working
> (using pure DBI does)
If you like, you can turn DBI_TRACE on and look at the SQL that
Class::DBI is running.
> 2. this worked fine before autocommit was turned off
I don't remember you mentioning that before. If something is not
getting committed to the database, that would cause the process that did
the insert to see it, and none of the others. You also should not be
able to see it when connecting to the database from a query tool if it
is not being committed.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
