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

Question

Jusqu'à présent, je l'ai utilisé PDO->bindParam mais en lisant le manuel que je trouve 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 que je trouve: PDO->closeCursor dois-je placer où il marqué? Est-il en option / automatiquement appelé? Il semble que certains pilotes ont besoin. Est-ce que l'appeler sur un pilote qui n'a pas besoin / la soutenir provoquer des erreurs? Que diriez-vous de 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 n'avez pas besoin closeCursor() lorsqu'il n'y a pas de résultats (i.e., seulement SELECT s ou des procédures qui donnent des résultats de retour), mais le plus souvent je l'ai déjà fait un endroit fetchAll dans un communiqué / ligne précédente.

Answer 2

Ce n'est pas vrai. Si vous vous trouvez avoir besoin d'utiliser closeCursor, l'un des plus optimales est temps pour une insertion / mise à jour / commandes de suppression, et rarement pour les instructions SELECT pour lesquels vous avez déjà récupérés résultats.

Par exemple, si vous sélectionnez tous les enregistrements d'une table, puis émettre stmt- $> fetch (), ce accomplit effectivement l'objectif de closeCursor immédiatement les lignes sont désormais plus dans un état non récupéré.

Dans le 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 base de données souffre de cette limitation, le problème peut se manifester par une erreur hors séquence.

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

• Si votre pilote 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 déclarations préparées et que vous souhaitez les exécuter un après l'autre ($ stmt1-> execute (); $ stmt-> closeCursor (); $ stmt2-> execute (); $ stmt2-> closeCursor ( ), stmt3 $ ... etc)
• Vous avez plusieurs stmts qui doit exécuter insertion / mise à jour / supprimer dans le même bloc. Cela est vrai parce que, si vous n'obtenez des résultats de ligne mysql en arrière, vous ne recevez pas le nombre de lignes affectées résultat arrière ensemble (ce qui est toujours un résultat).
• Lorsque vous utilisez des transactions
• Lorsque vous souhaitez émettre style sélectionnez préparé les déclarations 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à tiré par les cheveux les lignes (comme stmt- $> fetch ()) avant votre déclaration suivante doit être exécutée. A ce stade, les lignes sont dans un état « tiré par les cheveux » et permet de libérer le conducteur d'exécuter de nouvelles déclarations.

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é à tout éclaircir .

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