PDO-> bindParam, PDO-> bindValue y PDO-> closeCursor

Question

Hasta ahora he estado usando PDO->bindParam sin embargo al leer el manual de Me encontré PDO->bindValue de lo que puedo decir PDO->bindValue pasa por el valor en el que como PDO->bindParam pasa por referencia, es esta la única diferencia?

$modThread = db()->prepare("UPDATE `threads` SET `modtime` = UNIX_TIMESTAMP( ) WHERE `threadid` =:id LIMIT 1");

while(something)
{
        $modThread->bindParam(':id', $thread);
        $modThread->execute();
//*******************HERE********************//
}

Una vez más, mientras que la lectura del manual de I encontró: PDO->closeCursor debería colocarlo donde marcada? ¿Es opcional / llama automáticamente? Parece sólo ciertos conductores lo necesitan. Se calificó en un controlador que no necesita / apoyo que causan errores? ¿Qué hay de MySQL?

Answer 1

El bindParam() 'recurrente' aquí no es realmente necesario:

$thread = 0;
$modThread->bindParam(':id', $thread);

while($thread < 20)
{
    $thread++;
    $modThread->execute(); //executing with the new value, which you couldn't do with bindValue
}

Usted no necesita un closeCursor() cuando no hay un conjunto de resultados (es decir, sólo con la SELECT s o procedimientos que dan resultados de vuelta), pero por lo general ya se ha hecho un fetchAll algún lugar en una declaración / fila anterior.

Answer 2

Esto no es cierto. Si ves que necesitas para usar closeCursor, uno de los más momentos óptimos para los comandos de borrado es insertar / actualizar /, y rara vez para las sentencias SELECT para los que tiene resultados ya leídos.

Por ejemplo, si selecciona todos los registros de una tabla, a continuación, emitir $ stmt-> fetch (), esto en realidad cumple con el objetivo de closeCursor inmediatamente como las filas ya no están en un estado de no obtenidos.

Desde el manual:

Este método es útil para los conductores de bases de datos que no son compatibles con la ejecución de un objeto PDOStatement cuando un objeto PDOStatement previamente ejecutada aún tiene filas no captadas. Si los controladores de bases de datos sufre de esta limitación, el problema puede manifestarse en un error fuera de secuencia.

Cuando realmente se necesita es closeCursor durante cualquiera de los siguientes casos:

• Si el controlador de base de datos no permite un nuevo prop para ser ejecutado mientras que las filas no captadas están disponibles en la anterior ejecución
• Usted tiene múltiples declaraciones preparadas y desea ejecutarlas de un servicio post-otro ($ stmt1-> execute (); $ stmt-> closeCursor (); $ stmt2-> execute (); $ stmt2-> closeCursor ( ); $ stmt3 ... etc)
• Usted tiene múltiples stmts que debe ejecutar insertar / actualizar / borrar dentro del mismo bloque. Esto es así porque, aunque no te dan resultados fila mysql atrás, usted consigue el número de filas afectadas resultado de nuevo conjunto (que sigue es el resultado).
• Cuando se utiliza transacciones
• Cuando se desea emitir seleccionar al estilo de comandos preparados y ejecutarlos, pero no recuperar los datos hasta más tarde

Cuando no se necesita la declaración closeCursor:

• Si ya ha exagerado las filas (como con $ stmt-> fetch ()) antes de su próximo estado se va a ejecutar. En este punto, las filas están en un estado de "descabellada" y libera al conductor para ejecutar nuevas declaraciones.

Así como útil para cerrar un cursor no está definido () (es decir: unset ($ stmt)) y el establecimiento de la declaración de nulo ($ stmt = null), abriendo las puertas a la incorporada en el colector de basura para aclarar todo .

Consulte el manual para más información: http://php.net/manual/en /pdostatement.closecursor.php