[CDBI] Re: prepare_cached error?

Edward J. Sabol sabol at alderaan.gsfc.nasa.gov
Tue May 16 23:36:59 BST 2006

Eduardo Grosclaude wrote:
>> Please, can somebody point me to the cause for this error? The code,
>> database, locations, etc., do work in another, only more up to date
>> installation. Sqlite3 command line interface finds no problem with the DB.
>> What should I upgrade? TIA
>> Error executing run mode 'lst': DBD::SQLite::db prepare_cached failed: no
>> such table: contactos(1) at dbdimp.c line 269 [for Statement "SELECT cid
>> FROM contactos WHERE cid LIKE ? ORDER BY apellido "] at
>> /usr/lib/perl5/site_perl/5.8.6/Ima/DBI.pm line 381.
>> at /usr/lib/perl5/site_perl/5.8.6/CGI/Application.pm line 160
>> CGI::Application::run('Admin=HASH(0x839ade8)') called at
>> /var/www/html/linux/admin/admin.pl line 530

Matt Trout replied:
> Fire up the SQLite3 command-line client and send us the result of
> ".schema" - without seeing your database structure this is impossible
> to debug (apart from to guess "you screwed up somewhere", which isn't
> particularly useful :)

I figure Eduardo probably already checked that the "contactos" table already
exists. Rather, I suspect the prepare_cache() problem is the same one that
Tim Bunce and John Siracusa discussed in an e-mail (Message-ID:
<20060118113630.GB26897 at timac.local>) sent to this mailing list on Wed, 18
Jan 2006 11:36:30. I'll include the relevant portions of that conversation

   On Tue, Jan 17, 2006 at 08:12:48PM -0500, John Siracusa wrote:
   >>>> I explored that a while ago (Rose::DB::Object passes 3 as you
   >>>> suggest), but it still doesn't account for the situation where the db
   >>>> supports server-side prepared statements and the schema changes
   >>>> between calls. I encountered this in my benchmark suite, which
   >>>> creates and drops indexes as part of its execution. Any statement
   >>>> that was prepare_cache()d server-side when the indexes existed will
   >>>> fail if execute()d after the indexes are dropped.

   On Wed, 18 Jan 2006 11:36:30 +0000, Tim Bunce replied:
   >>> That's a database-specific issue. What database were you using?
   >>> (SQLite has this problem. The author has said that it could simply
   >>> re-prepare the execution plan for the statement but currently it just
   >>> returns an error. Very annoying, but not common with other databases.)

Eduardo, are you dropping or creating indexes (or otherwise changing the
schema) between the time you first query this database table and when you
receive this error? If so, Tim Bunce also offered the following solution for

   >>> It's also possible to $dbh->{CachedKids} = {} to clear out the cached
   >>> statement handles explicitly if desired. (Such as when you're using
   >>> SQLite and know the schema has changed.)

Hope this helps,

More information about the ClassDBI mailing list