PDO-> bindParam, PDO-> bindValue et PDO-> closeCursor

Question

Jusqu'à présent, je l'ai utilisé PDO->bindParam mais en lisant le manuel, j'ai trouvé PDO->bindValue de ce que je peux dire PDO->bindValue passe par la valeur alors que PDO->bindParam passe par référence, est-ce la seule différence?

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

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

Encore une fois en lisant le manuel, j'ai trouvé: PDO->closeCursor dois-je placer où il marqué? Est-il optionnel/automatiquement appelé? Il semble que seuls certains conducteurs en ont besoin. Est-ce que l'appel sur un driver qui n'a pas besoin de/support le cause des erreurs? Pourquoi pas MySQL?

Answer 1

Le « » récurrent bindParam() ici est pas vraiment nécessaire:

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

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

Vous ne ont pas besoin closeCursor() lorsqu'il n'y a pas de résultats (c.-à-seulement SELECT s ou des procédures restituant les résultats), mais le plus souvent J'ai déjà fait un fetchAll quelque part dans une déclaration/rangée précédente.

Answer 2

Ceci n'est pas vrai. Si vous avez besoin d'utiliser closeCursor, l'un des meilleurs moments est pour les commandes insert/update/delete, et rarement pour les instructions SELECT pour lesquelles vous avez déjà obtenu des résultats. Par exemple, si vous sélectionnez tous les enregistrements d'une table, puis que vous exécutez $ stmt-> fetch(), l'objectif de closeCursor est immédiatement atteint, car les lignes ne sont plus dans un état non extrait.

A partir du manuel:

Cette méthode est utile pour les pilotes de base de données qui ne prennent pas en charge l'exécution d'un objet PDOStatement lorsqu'un objet PDOStatement exécuté précédemment a encore des lignes non récupérées. Si votre pilote de base de données souffre de cette limitation, le problème peut se manifester dans une erreur hors séquence.

Lorsque vous aurez vraiment besoin closeCursor est au cours de l'un des cas suivants:

• Si votre pilote de DB ne permet pas une nouvelle stmt à exécuter en lignes non récupérées sont disponibles à partir de la précédente exécution
• Vous avez plusieurs instructions préparées et vous souhaitez les exécuter les unes après les autres ($ stmt1-> execute(); $ stmt-> closeCursor(); $ stmt2-> execute(); $ stmt2-> closeCursor () $ stmt3 ... etc)
• Vous avez plusieurs stmts qui doivent exécuter insert/update/delete à l'int Ame bloc. C'est vrai parce que, bien que vous n'obteniez pas les résultats des lignes mysql, vous obtenez le résultat du nombre de lignes affectées (qui est toujours un résultat).
• Lors de l'utilisation des transactions
• Lorsque vous voulez faire des déclarations préparées de sélection de style et les exécuter, mais pas récupérer les données plus tard

Lorsque vous n'avez pas besoin de la déclaration closeCursor:

• Si vous avez déjà récupéré les lignes (comme avec $ stmt-> fetch()) avant que votre instruction suivante ne soit exécutée. À ce stade, les lignes sont dans un état "récupéré" et libère le pilote pour exécuter de nouvelles instructions.

Tout comme utile pour la fermeture d'un curseur est unset() (ex: unset ($ stmt)) et le réglage de la déclaration à null ($ stmt = null), ouvrant les portes pour le Garbage Collector intégré pour Tout effacer

Voir le manuel pour plus d'informations: http://php.net/manual/en/pdostatement.closecursor.php