PDO-> BindParam, PDO-> bindValue e PDO-> closeCursor

Question

Finora ho utilizzato PDO->bindParam tuttavia durante la lettura del manuale ho trovato PDO->bindValue da quello che posso dire PDO->bindValue passa per valore dove come PDO->bindParam passa di riferimento, è questa l'unica differenza?

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

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

Anche in questo caso durante la lettura del manuale ho trovato: PDO->closeCursor dovrei metterlo dove segnata? E 'opzionale / chiamata automaticamente? Sembra solo alcuni piloti hanno bisogno. Sarà definendolo su un driver che non ha bisogno / supportano causare errori? Che ne dite di MySQL?

Answer 1

Il bindParam() 'ricorrente' qui non è davvero necessario:

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

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

Non è necessario un closeCursor() quando non c'è di risultati (cioè, solo con SELECT s o procedure che danno risultati indietro), ma di solito ho già fatto un qualche fetchAll in un precedente comunicato / riga.

Answer 2

Questo non è vero. Se vi trovate a dover utilizzare closeCursor, uno dei tempi più ottimale è per inserimento / aggiornamento / comandi di cancellazione, e raramente per le istruzioni SELECT per cui si dispone risultati già recuperati.

Ad esempio, se si seleziona tutti i record di una tabella, poi emettere $ stmt-> fetch (), questo compie in realtà l'obiettivo per closeCursor immediatamente come le righe non sono più in uno stato non recuperato.

Dal manuale:

  

Questo metodo è utile per i driver di database che non supportano l'esecuzione di un oggetto PDOStatement quando un oggetto PDOStatement eseguito in precedenza ha ancora le righe non recuperato. Se il driver di database soffre di questa limitazione, il problema può manifestarsi in un errore out-of-sequenza.

Quando si sarà davvero bisogno closeCursor è durante uno dei seguenti casi:

• Se il driver DB non consente una nuova stmt da eseguire, mentre le righe non recuperato sono disponibili dal precedente eseguire
• Si dispone di più istruzioni preparate e vorreste eseguirli uno dopo l'altro-($ stmt1-> execute (); $ stmt-> closeCursor (); $ stmt2-> execute (); $ stmt2-> closeCursor ( ); $ stmt3 ... etc)
• Si dispone di più stmts che deve eseguire inserimento / aggiornamento / cancellare all'interno dello stesso blocco. Questo è vero perché, mentre non si ottengono risultati di fila MySQL indietro, si ottiene il numero di righe coinvolte risultato di nuovo insieme (che è ancora un risultato).
• Quando si utilizza le transazioni
• Quando si desidera rilasciare selezionare stile istruzioni preparate e li esegue, ma non recuperare i dati fino al più tardi

Quando non è necessario la dichiarazione closeCursor:

• Se avete già recuperato le righe (come con $ stmt-> fetch ()) prima della prossima dichiarazione deve essere eseguito. A questo punto i file sono in uno stato "recuperato" e consente di liberare il conducente di eseguire nuove dichiarazioni.

Proprio come utile per la chiusura di un cursore è impostata () (vale a dire: unset ($ stmt)) e impostando la dichiarazione per nulla ($ stmt = null), aprendo le porte per il built-in Garbage Collector per chiarire tutto in su .

Vedere il manuale per maggiori informazioni: http://php.net/manual/en /pdostatement.closecursor.php