Re: DBI "drop table"

Placeholders for table and column names are not supported (I don't know if that's a DBI or a MySQL restriction). So you can't use the prepare($sql); execute($tablename) scheme here.

You can run the the table name through $dbh->quote method instead, and interpolate it into the SQL.

(BTW instead of writing or die "$DBI::errstr" behind each operation you can just as well use the RaiseError => 1 option in connect).

Comment on Re: DBI "drop table" Select or Download Code

Replies are listed 'Best First'.
Re^2: DBI "drop table" by ikegami (Patriarch) on Apr 12, 2008 at 20:32 UTC
Placeholders for table and column names are not supported (I don't know if that's a DBI or a MySQL restriction). I think most databases have that restriction. I think they need the table names to properly prepare. You can run the the table name through $dbh->quote method instead, and interpolate it into the SQL. No. `$dbh->quote` is for string literals only. For example, it's valid for `$dbh->quote("one\ntwo\0three")` to return `CONCAT('one', CHAR(12), 'two', CHAR(0), 'three')`. `$dbh->quote_identifier` is the appropriate function here.	[reply] [d/l] [select]
Re^3: DBI "drop table" by tinita (Parson) on Apr 13, 2008 at 11:18 UTC
I think most databases have that restriction. I think they need the table names to properly prepare. i recently stumbled across this while trying to make an application compatible with SQLite. in SQLite the table even has to exist - otherwise a prepare for a drop-statement will fail. so if you prepare all your statements at the start of your script, and you have create- and drop-statements also (e.g. for temporary tables) this won't work in SQLite. but i'd think this could be a bug because i don't know why a prepare for a drop should need the existing table.	[reply]