At this point your guess is as good as mine as I've no time to dig deeper. Sorry.
Tim. On Wed, Apr 19, 2006 at 01:07:35PM +0800, Allan Dyer wrote: > On 18 Apr 2006 at 23:00, Tim Bunce wrote: > > On Mon, Apr 10, 2006 at 03:14:21PM +0800, Allan Dyer wrote: > > > > > > > > > > I've found that the problem with table_info has been reported three > > > > > times before in this group: > > > > > > > > Here's how I call table_info(...). I have not used DBD::Proxy. > > > > > Who's maintaining DBD::Proxy? Perhaps I should contact them direct. > > > > I'd *love* someone to help maintain DBD::Proxy. Any volunteers? > > Sorry, I can't commit on this. I can help document this problem, and test any > solutions suggested. > > > Meanwhile, see this in Proxy.pm: > > > > # XXX probably many more methods need to be added here. > > # See notes in ToDo about method metadata > > sub commit; > > sub connected; > > sub rollback; > > sub ping; > > > > try adding extra lines for any methods that seem unsupported by DBD::Proxy. > > I didn't find any explanation of method metadata in ToDo, so I added: > sub table_info; > sub column_info; > > > Please let me know if that helps. > > For my column_info example, a change. I previously got: > Can't call method "fetchall_hashref" on an undefined value at ./example2.pl > line 17. > Now I get: > DBD::Proxy::db column_info failed: Server returned error: Failed to execute > method CallMethod: Can't call method "execute" without a package or object > reference at /usr/lib/perl5/site_perl/5.8.8/i486-linux/DBI.pm line 1584. > > For my table_info example, no change, I still get: > DBD::Proxy::db table_info failed: Server returned error: Failed to execute > method CallMethod: Can't call method "execute" without a package or object > reference at /usr/lib/perl5/site_perl/5.8.8/i486-linux/DBD/mysql.pm line 262. > > it seems that table_info in mysql.pm is not getting a valid statement handle, > which implies the database handle it has been given is invalid. I looked at > ProxyServer.pm and found this comment in table_info: > > # We wouldn't need to send all the rows at this point, instead we could > # make use of $rsth->fetch() on the client as usual. > # The problem is that some drivers (namely DBD::ExampleP, DBD::mysql and > # DBD::mSQL) are returning foreign sth's here, thus an instance of > # DBI::st and not DBI::ProxyServer::st. We could fix this by permitting > # the client to execute method DBI::st, but I don't like this. > > I'm wondering if this is related, but I'm finding it difficult to follow > what's > happening. Did the behaviour of DBD::mysql change after DBD:Proxy was > written, > perhaps? > > Allan > > > -------------------------------------------------------------------- > Allan Dyer, CISSP, MHKCS, MIAP | [EMAIL PROTECTED] > Chief Consultant | http://www.yuikee.com.hk/ > Yui Kee Computing Ltd. | +852 28708555 >
