SQLite3Stmt::execute

(PHP 5 >= 5.3.0, PHP 7, PHP 8)

SQLite3Stmt::executeВыполняет подготовленный запрос и возвращает объект с результирующим набором

Описание

public SQLite3Stmt::execute(): SQLite3Result|false

Выполняет подготовленный запрос и возвращает объект с результирующим набором.

Предостережение

Объекты результирующего набора, полученные при вызове этого метода для одного и того же объекта подготовленного запроса, не являются независимыми, а используют одну и ту же базовую структуру. Поэтому рекомендуется вызвать SQLite3Result::finalize(), прежде чем вызывать SQLite3Stmt::execute() на том же объекте подготовленного запроса снова.

Список параметров

У этой функции нет параметров.

Возвращаемые значения

Возвращает объект SQLite3Result в случае успешного выполнения подготовленного запроса и false в случае возникновения ошибки.

Смотрите также

  • SQLite3::prepare() - Подготавливает SQL-запрос для выполнения
  • SQLite3Stmt::bindValue() - Связывает значение параметра с переменной подготовленного запроса
  • SQLite3Stmt::bindParam() - Связывает параметр с переменной подготовленного запроса
add a note add a note

User Contributed Notes 2 notes

up
10
gmail@asmqb7
8 years ago
There's currently an issue in the SQLite3 PHP binding (not SQLite3 itself) that causes all queries to be executed twice. It has apparently existed for quite a while.

See here for more info: https://bugs.php.net/bug.php?id=64531

Before discovering the above, I posted this: http://stackoverflow.com/questions/36617708/odd-behavior-with-sqlite3-non-select-prepared-transactions-and-fetcharray (includes copy-paste bug demo)

Workaround: I strongly recommend wrapping any code that might run fetchArray() on non-SELECT query results inside a numColumns() check, like this:

<?php

$op
= $db->prepare(...);

$r = $op->execute(); // query #1

if ($r->numColumns()) { // returns column count, here being used as true/false test
 
while ($row = $r->fetchArray(SQLITE3_ASSOC)) { // query #2
    // your code here
 
}
}

?>

To clarify:

- Query #1 is where the SQLite3 query is executed the first time, query #2 is where the query is executed again. Yes, *everything* is executed twice; this is the bug.

- If your code will only read from and not alter the database (so, a SELECT that won't cause database-altering triggers to run, for example), you're fine. Your query runs twice but it doesn't alter the result.

- If your code will write to the database - for example an INSERT - you MUST not run fetchArray() (and execute the query again) if the number of columns is zero.

- It's not documented in the manual but over here -http://php.net/manual/en/book.sqlite3.php#113144 - user 'bohwaz' mentions that there's also a SQLite3Stmt::readOnly() function since PHP 5.3.11 which will tell you if you just wrote to the DB. This is currently undocumented but might be a more appropriate alternative to numColumns() (I'm not sure what it does, it might be the same).

You might prefer PDO for higher-volume work with SQLite3. This binding is ironically lighter-weight and provides direct access to some SQLite3-specific primitives and behavior... but it runs all queries twice.

[[Note to moderators (this section may be deleted once it has been read; I'm also fine with feedback on the following):

- Please don't consider this comment a bug report - I just want others to be aware of this issue so they don't have to bumble around for hours scratching their heads. :P

- As of the submission date of this comment, there's a unapproved diff for this page stuck in DocBook so I can't add something like "due to bug #64531, you are recommended to wrap fetchArray() inside numColumns()...", which I think would carry more weight than this comment until this bug is fixed.]]
up
1
macguru
7 years ago
I had luck in avoiding prepared statements from executing multiple times by finalize()'ing the result after execution.

$stmt->execute()->finalize();

Hope this helps others.
To Top