[PDO + Oracle] : Problème de taille de donnée

Avatar du membre
Modérateur PHPfrance
Modérateur PHPfrance | 8758 Messages

08 nov. 2011, 11:58

Bonjour,

J'ai un problème avec l'utilisation de PDO et de oracle 11g (d'après ce que j'ai pu voir c'est pas forcément lié à oracle mais bon).

j'effectue un bête select
<?php
 public final function listprod(){
        $sql = 'SELECT codart, libart, stkphy,stkale, unimes from produit order by codart';
        try {
            $result = $this->pdo->query($sql);
            if ($result !== false){
                $r = $result->fetchALL(PDO::FETCH_OBJ);
                $result->closeCursor();
            }
            return $r;
        }
         catch (Exception $e) {
             throw new Exception ($e->getMessage());
         }
    }
?>
la classe contient bien en privée une variable nommé PDO qui est une instance de la classe PDO.
jusque la pas de soucis, ou presque j'ai ce message d'erreur sur le fetchAll()
Warning: PDOStatement::fetchAll() [pdostatement.fetchall]: column 4 data was too large for buffer and was truncated to fit it in C:\xampp\htdocs\papyrus\classes\commande.class.php on line 60
Par conte la suite est l'affichage et lui m'affiche toute les infos (et les bonnes hein :) )

Je ne comprends pas ce message d'erreur sachant que je l'ai deux fois sur 15 tuple et pas toujours sur la même colonne
message total
Warning: PDOStatement::fetchAll() [pdostatement.fetchall]: column 4 data was too large for buffer and was truncated to fit it in C:\xampp\htdocs\papyrus\classes\commande.class.php on line 60

Warning: PDOStatement::fetchAll() [pdostatement.fetchall]: column 4 data was too large for buffer and was truncated to fit it in C:\xampp\htdocs\papyrus\classes\commande.class.php on line 60

Warning: PDOStatement::fetchAll() [pdostatement.fetchall]: column 1 data was too large for buffer and was truncated to fit it in C:\xampp\htdocs\papyrus\classes\commande.class.php on line 60

Warning: PDOStatement::fetchAll() [pdostatement.fetchall]: column 1 data was too large for buffer and was truncated to fit it in C:\xampp\htdocs\papyrus\classes\commande.class.php on line 60
docn 4 messages d'erreurs sur la même ligne (le fetchAll()).

exemple de donnée
B001 Bande magnétique 1200 87 20 unit <= manque le é
B002 Bande magnétique 6250 12 20 unit <= idem
D035 CD R slim 80 mm 42 40 B010
D050 CD R-W 80mm 4 50 B010
P240 Pré-imprimé bulletin pa 3000 500 B500 <= manque deux caractères pour paie
P250 Pré-imprimé bon livrais 2500 500 B500 <= manque deux caractères pour livraison
P270 Pré-imprimé fabrication 2500 500 B500

Je suis tombé la dessus https://bugs.php.net/bug.php?id=35003&edit=1 qui semble dire qu'il s'agit la d'un bug non résolus, mais heu je n'arrive pas a tout suivre.

D'autre site parle de renommage de colonne (les miennes ne font que 6 caractères max) bref j'ai pas trop pigé d'où cela peux venir.

Je viens de voir que sur deux lignes le résultat est effectivement tronqué à 24 caractères dans la 2ème colonne (donc la 1 si l'on par de zéro) soit les deux dernier messages d'erreur.
les deux premières lignes les é sont virés et ce n'est pas un problème de longueur de données, car "unité" on vire le é et "unite" est fournit complet.

je précise que j'indique le charset utf8 lors de la connexion (dns = 'oci:dbname=//localhost/instance;charset=UTF8').
Je ne sais pas si cela peux venir de la, une ou deux page en parle, et pour être je ne sais pas comment oracle gère cela j'ai pas encore regardé.

j'ai quand même des données avec des accents qui s'affichent sans problème (dernière de l'exemple ci dessus) ....

Ma question est donc : Est ce que quelqu'un a déjà eu ce type de de problème et comme l'a t'il résolu :)

D'ailleurs au passage, est ce que quelqu'un sais comment forcer oracle à filer des noms de colonnes en minuscule (parce que j'aime pas le upper case forcé na :mrgreen: ).

voila c'est tout pour le moment, merci de votre patience :)

@+
Il en faut peu pour être heureux ......

ViPHP
xTG
ViPHP | 7331 Messages

08 nov. 2011, 12:16

Les noms de colonne non tu ne peux pas, même en faisant un create table avec des noms en minuscules ils les prends comme des majuscules... Mais pas dans les autres requêtes ce qui est assez chiant...

Pour ton problème de buffer... J'ai rien trouvé non plus. J'en ai parlé à un ami qui travaille avec un sgbd Oracle mais il a abandonné l'idée d'utiliser PDO pour ce dernier à cause de ce bug persistant depuis des années (il a été découvert en 2007 si je me souviens bien ce qu'il a dit).
Il passe uniquement via OCI8.

ViPHP
ViPHP | 2577 Messages

08 nov. 2011, 12:43

J'avais utilisé Oracle + PHP il y a quelques années, la fonction correspondant à mysql_errno() ne fonctionnait pas et j'étais obligé de récupérer les erreurs dans la sortie avec les fonctions de bufferisation ob_?????().

Avatar du membre
Modérateur PHPfrance
Modérateur PHPfrance | 8758 Messages

08 nov. 2011, 14:39

(il a été découvert en 2007 si je me souviens bien ce qu'il a dit).
j'ai vue 205 mais bon, c'est la même chose.
ceci dit c'est mis que l'extension est pas fiable dans la doc :/

ça me fait chier vu que dans ma formation c'est oracle plein pot (sgbd oracle + java ^^).

Je voulais tester la "puissance" de PDO, a savoir la possibilité de changer de sgbd sans touche le reste ou peux et je me rend compte qu'en fait c'est quand même le merdier :)

rien que pour restreindre le nombre de tuple du resultat, mysql / postgres limit, oracle rownum, je suis encore bien tombé :mrgreen:

bon ben merci pour les info, je vais voir ce que ça donne avec java, mais je vais pouvoir tacler le formateur la prochaine fois qu'il me diras qu'oracle ça marche avec tout et que c'est super bien :mrgreen:

merci

@+
Il en faut peu pour être heureux ......

ViPHP
xTG
ViPHP | 7331 Messages

08 nov. 2011, 15:23

PDO est loin d'être une bonne interface, cela vient du fait qu'on écrit toujours des requêtes en dur. :)
Vu que chaque sgbd a ses propres "normes" et ses propres fonctions on peut pas s'en sortir facilement.
Car même en suivant strictement les recommandations SQL il y a toujours quelques SGBD qui n'intègrent pas tout...

Le mieux dans ces cas là c'est vraiment de passer par un ORM.
Après faut aimer... Et pas avoir besoin d'optimisations SQL. Mais qui dit optimisation SQL de manière dit SQL DU sgbd en question donc bon...

Oracle est un très bon SGBD, mais encore faut-il l'attaquer avec les bons outils. ^^

Pour finir, bon courage pour ta formation, j'ai aussi un cours de JEE et pour ma part je trouve les Servlets bien horribles. ^^
J'espère que quand on attaquera Struts ou autre on aura un aspect différent de la chose... Car pour le moment je me sens pas le moins du monde attiré.

Avatar du membre
Modérateur PHPfrance
Modérateur PHPfrance | 8758 Messages

08 nov. 2011, 17:03

bon en fait c'est bien un pb de charset dès que je vire les accent ça déconne plus ^^

quand au reste ben j'vais pas essayer d'utiliser un orm pour des pages web qui servent a rien d'autre qu'a m'occuper pendant les heures de cours où je me fait chier parce que je connais déjà :mrgreen:

info mici pour les info

@+
Il en faut peu pour être heureux ......