Thanks for your answers, Corion. I'm using MySQL, but I don't think MySQL is preventing multiple statements, since from the Linux prompt I can echo multiple SQL commands and pipe them to a mysql command and they work. From looking below at chacham's answer, it looks as if DBI prevents it, which is fine by me.
Re^2: Multiple SQL statements in DBI
Replies are listed 'Best First'.
I don't think DBI prevents anything. It passes the text you give it to the database to parse. If the mysql command line takes multiple statements, then the command line tool is likely parsing separate statements. Likewise, in Oracle, you can pass multiple SQL statements to sqlplus, but not to DBI, because sqlplus does some parsing of its own.
I do see that the latest version of DBD::mysql supports multiple result sets. You might want to look into that.
Thanks for that runrig, but why do you say "I don't think DBI prevents anything", when as chacham has pointed out below, the 'DBI documentation states "Multiple SQL statements may not be combined in a single statement handle ($sth), although some databases and drivers do support this (notably Sybase and SQL Server)."'. To me, that means, regardless of whether the database driver supports it, DBI will prevent it. Or am I misunderstanding something?
I don't believe DBI prevents any SQL. As far as I am aware prepare is a method in the individual DBDs. I don't believe that quote from the DBI pod has anything to do with SQL injection.
Just a few reasons why multiple SQL statements in the same prepare/do call are problematic (or unsupportable as is):
Some DBDs "parse" (mostly roughly) the SQL passed to prepare in order to try and identify placeholders. e.g., DBD::ODBC does this but only because DBI says placeholders may be specified with :name or ? and ODBC itself only defines the latter. I doubt vey much that of those DBDs which parse the SQL to find placeholders many (if any) support recognising N bits of SQL separated by ; So imagine if you did "insert into mytable values(?);insert into mytable values(?)" then any DBD which parses the SQL looking for placeholders may be fooled into thinking you need 2 but in actual fact the database probably executes these sepately.
Generally speaking the databases which support multiple statements in the same prepare run them individually and often there is something required to make it move from one to the next. Imagine 2 select stmts for differing numbers of columns - you need to stop in between them. Imagine an insert followed by another insert (your example), what is to be returned by execute when it is defined as returning the number of affected rows.
Then there are batch statements like execute_for_fetch and execute_array. How is the tuple status to be returned for multiple statements.