And that is the correct primary key for this table?
yes
> 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?
nothing, you wanted to see it :) sometimes that list is 1 short
> 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?
correct, same behavior, sometimes it was in the list, sometimes it wasn't. i.e. problems are not related to method of retrieval using Class::DBI
> 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.
will try
> 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.
OK, but remember: most children DO show the right data, including the one that made the insert. If only the child that made the insert showed that new data, then we'd know this is the problem, right?
-- 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
