AOP Non-requêtes

Que j'essaie de faire en AOP de détails. Donc j'ai codé ceci:

$cn = getConnection();

//get table sequence
$comando = "call p_generate_seq('bitacora')";
$id = getValue($cn, $comando);

//$comando = 'INSERT INTO dsa_bitacora (id, estado, fch_creacion) VALUES (?, ?, ?)';
$comando = 'INSERT INTO dsa_bitacora (id, estado, fch_creacion) VALUES (:id, :estado, :fch_creacion)';
$parametros = array (
    ':id'=> (int)$id,
    ':estado'=>1,
    ':fch_creacion'=>date('Y-m-d H:i:s')
);
execWithParameters($cn, $comando, $parametros);

mon getValue fonction fonctionne très bien, et j'obtiens la séquence suivante de la table. Mais quand je suis dans l'execWithParameters, j'ai cette exception:

PDOException: SQLSTATE[HY000]: General error: 2014 Ne peut pas exécuter des requêtes, tandis que d'autres barrettes de mémoire les requêtes sont actifs. Envisager l'utilisation de la méthode PDOStatement::fetchAll(). Alternativement, si votre code n'est jamais aller à l'encontre de mysql, vous pouvez permettre à une requête de mise en mémoire tampon par le réglage de la PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribut. dans D:\Servidor\xampp_1_7_1\htdocs\bitacora\func_db.php sur la ligne 77

J'ai essayé de modifier les attributs de connexion mais ça ne fonctionne pas.

Ce sont mes core db fonctions:

function getConnection() {
    try {
        $cn = new PDO("mysql:host=$host;dbname=$bd", $usuario, $clave, array(
                PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
            ));

        $cn->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, true);
        return $cn;
    } catch (PDOException $e) {
        print "Error!: " . $e->getMessage() . "<br/>";
        die();
    }
}
function getValue($cn, $comando) {
    $resul = $cn->query($comando);
        if (!$resul) return null;
        while($res = $resul->fetch()) {
            $retorno = $res[0][0];
            break;
        }
        return $retorno;
}
function execWithParameters($cn, $comando, $parametros) {
    $q = $cn->prepare($comando);
    $q->execute($parametros);
    if ($q->errorInfo() != null) {
        $e = $q->errorInfo();
        echo $e[0].':'.$e[1].':'.$e[2];
    }
}

Quelqu'un qui peut apporter un éclairage pour cela? PD. S'il vous plaît ne vous le conseille pas autonumeric id, parce que je suis portage à partir d'un autre système.

Quelle est la définition de p_generate_seq? MONTRER PROCÉDURE p_generate_seq
le problème ne réside pas là, la même erreur se produit avec SELECT MAX(id) from dsa_bitacora

OriginalL'auteur Jhonny D. Cano -Leftware- | 2009-05-08

pdo php

21

Le problème est que mysql ne permet une circulation curseur à un moment donné. En utilisant le fetch() et ne consomme pas toutes les données en attente, vous laissant un curseur ouvert.

L'approche recommandée consiste à consommer toutes les données à l'aide de la méthode fetchAll ().
Une alternative est d'utiliser le closeCursor() la méthode.

Si vous modifiez cette fonction, je pense que vous serez plus heureux:
```
<?php
function getValue($cn, $comando) {
    $resul = $cn->query($comando);
    if (!$resul) return null;
    foreach ($resul->fetchAll() as $res) {
            $retorno = $res[0];
            break;
    }
    return $retorno;
}
?>
```
Je sais utiliser les fonctions de connexion comme ci-dessus mais qui ont le même problème. La méthode fetchALL() ne semble pas fonctionner sur ma machine correctement. Des conseils ou des solutions de rechange depuis votre réponse?

OriginalL'auteur Wez Furlong
16

Je ne pense pas que la méthode PDOStatement::closeCursor() si vous ne faites pas une requête qui renvoie des données (c'est à dire une mise à JOUR, INSERTION, etc).

Une meilleure solution est tout simplement de la fonction unset() votre objet PDOStatement après l'appel de la méthode PDOStatement::execute():
```
$stmt = $pdo->prepare('UPDATE users SET active = 1');
$stmt->execute();
unset($stmt);
```
dois vérifier, merci
Eu le même problème en php une fonction récursive. Merci pour cette réponse le problème est résolu comme ceci: $rows = $sth->fetchAll(PDO::FETCH_ASSOC); unset($sth); foreach ($lignes as $row). Ce que j'avais précédent : while ($row = $sth->fetch(PDO::FETCH_ASSOC)). Merci!!!!

OriginalL'auteur
8

Le problème semble être---je ne suis pas trop familier avec PDO--- qu'après votre getValue retours d'appel, la requête est toujours lié à la connexion (Vous ne jamais demander pour la première valeur, pourtant, la connexion revient à plusieurs, ou prévoit de le faire).

Peut-être getValue peut être corrigé en ajoutant
```
$resul->closeCursor();
```
avant le retour.

Autrement, si les requêtes de getValue retournera toujours un seul (ou assez peu) de valeur, il semble que l'utilisation de fetchAll sera préféré.

tx... j'ai juste essayé le closeCursor et le fetchAll, et il ne cesse de soulever la même exception.

OriginalL'auteur Tordek
3

Je viens de passer 15 minutes à googler tout autour de l'internet, et de voir au moins 5 différents Stackoverflow questions, certains qui prétendaient mon bug apparemment surgi de la mauvaise version de PHP, d'une mauvaise version de MySQL bibliothèque ou tout autre magique "boîte noire" des choses...

J'ai changé tout mon code en utilisant "fetchAll" et j'ai même appelé closeCursor() et la fonction unset() sur l'objet de requête après chaque requête. J'ai été franchement à perdre tout espoir! J'ai aussi essayé la MYSQL_ATTR_USE_BUFFERED_QUERY drapeau, mais il n'a pas de travail.

ENFIN j'ai jeté le tout par la fenêtre et regarda à l'erreur PHP, et de suivi de la ligne de code où il est passé.
```
SELECT AVG((original_bytes-new_bytes)/original_bytes) as saving 
    FROM (SELECT original_bytes, new_bytes FROM jobs ORDER BY id DESC LIMIT 100) AS t1
```
De toute façon, le problème qui s'est passé parce que mon original_bytes et new_bytes la fois où unsigned bigints, ce qui signifie que si j'ai jamais eu un emploi où l'new_bytes où, en fait, PLUS grande que la original_bytes, alors je serais un méchant MySQL "hors de portée" erreur. Et c'est juste arrivé au hasard après l'exécution de mon minification du service pour un peu de temps.

Pourquoi diable je l'ai eu cette étrange erreur MySQL au lieu de juste me donner la plaine d'erreur, est au delà de moi! Il est en réalité montré dans SQLBuddy (léger PHPMyAdmin) quand j'ai couru le raw de la requête.
J'ai eu les exceptions de PDO, donc il aurait du juste de me donner l'erreur MySQL.

Jamais l'esprit, la ligne de fond est:

Si vous obtenez cette erreur, assurez-vous de vérifier que votre raw MySQL est correcte et fonctionne TOUJOURS!!!

Juste face à cette énigmatique et inutile d'erreur, et grâce à qui answert j'ai pensé à l'extérieur de la boite pour un moment. SHOW WARNINGS sur la même connexion, dans lequel la requête a échoué s'est révélée cruciale pour déboguer. Dans mon cas, l'erreur était: Unknown or incorrect time zone: 'Europe/London' lequel j'ai défini lors de la création de l'instance de PDO. Merci @Henrik.

OriginalL'auteur Henrik
0

Un ami à moi avait très bien le même problème avec xampp 1.7.1 construire. Après le remplacement de xampp/php/* par la 5.2.9-2 php.net construire et copie tous les fichiers nécessaires pour xampp/apache/bin il a bien fonctionné.

OriginalL'auteur VolkerK
0

Si vous utilisez XAMPP 1.7.1, vous avez juste besoin de mettre à niveau vers 1.7.2.

OriginalL'auteur Khashayar

Vous devez vous connecter pour publier un commentaire.