Comprendre PDO [Article]

[dorian53]

Oké merci , ça me rassure.

[beegees]

Bonjour,

Je trouve que c'est un bon tuto qui va beaucoup m'aider dans mon apprentissage.

Merci.

beegees

[FMaz]

Envoyé par beegees

Bonjour,

Je trouve que c'est un bon tuto qui va beaucoup m'aider dans mon apprentissage.

Merci.

beegees

Me voilà heureux alors ! Bonne route !

[Asli Bilal]

Bonjour,

Il me semble avoir vu une petite faute dans l'instanciation de la connexion.

Code :

$pdo = new PDO($connStr, 'Utilisateur', 'Mot de passe', $arrExtraParam);

au lieu de :

Code :

$pdo = new PDO($strConnection, 'Utilisateur', 'Mot de passe', $arrExtraParam);

Sinon merci pour ce tuto,
Bilal

[redoran]

L'article à été écris pour être une base d'apprentissage saine à PDO. J'ai donc essayé de casser certains "mythes". Par la suite, la lecture d'article plus poussée devrait être facilité.

toute a fait d'accord , personnellement j'ai appris pas mal de choses encore bravo +++
juste faut voir le format pdf qui est un peut mal imprimer (page 8) .

[christele_r]

Bonjour,
Je découvre bien tardivement ton TOPO sur PDO !
Un vrais bijoux, et pour cela mille bravos

Je sais qu'il faut garder la "légéretée" a ton sujet, il n'empéche que
le mécanisme du PREPARE qui reste un pilier de PDO
(pas obligatoir comme tu l'a souligné) mériterait quelques précisions.

A ce sujet je te soumet une analyse dont tu fera le trie si bon te semble
pour l'incorporer si tu juges que cela n'alourdirait pas ton sujet.

____________________________________
Préparé ou pas, avec ou sans bindparam, au final chaque exec envoie en une seule fois la requête et les vraies variables au gestionnaire de base de données (par exemple MySql) a la différence du PREPARE SQL !

Dans un PREPARE (SQL par exemple) le gestionnaire reçoit et analyse la requête et attend tout envoi de données sur le pointeur de l'instruction préparée.

Voilà pour le prépare ...
______________________________________

Concernant "protection" "injection" et "échappement"

l' injection doit être évitée par un contrôle (de notre choix)

Pour le reste "protection" "échappement"

Juste un petit historique que vous connaissez bien sur:

Au début nous faisions avant un INSERT ou autre ... le fameux addslashes()
avec la douce contrainte de contrôler l'état d' activation de ou non des magic_quotes_gpc...

le résultat .. plein d' antislashs et obligé a la relecture de faire un
stripslashes()

Maintenant, les versions modernes de SQL / PHP ont cette superbe fonction
mysql_real_escape_string qui fait EXACTEMENT la même chose que PDO

A savoir doubler les ' et inscrire les caractères spéciaux et accentués sur deux octets ! ce qui protége bien les données.

Ainsi la relecture est directe sans instructions !!
____________________________________

A++ et encore BRAVO !
Christele

[sabotage]

Préparé ou pas, avec ou sans bindparam, au final chaque exec envoie en une seule fois la requête et les vraies variables au gestionnaire de base de données (par exemple MySql) a la différence du PREPARE SQL !

Pour Mysql (je ne sais pas pour les autres drivers), la préparation est par défaut émulé par soucis de compatibilité avec mysql < 5.1 mais il est possible d'utiliser la préparation du serveur mysql en changeant le paramètre ATTR_EMULATE_PREPARES.

Maintenant, les versions modernes de SQL / PHP ont cette superbe fonction
mysql_real_escape_string qui fait EXACTEMENT la même chose que PDO

pas vraiment moderne : cette fonction existe depuis 11 ans et est maintenant classé comme obsolète à ne plus utiliser.
Quand au fait qu'elle ferrait la même chose que PDO je ne vois pas trop à quoi tu fais référence.

A savoir doubler les ' et inscrire les caractères spéciaux et accentués sur deux octets ! ce qui protége bien les données.

Les accents ne posent pas de problème dans les requêtes et ne sont pas modifiés par mysql_real_escape_string. Ca serait d'ailleurs bien gênant d'avoir des caractères multioctet dans un encodage simple octet non ?

[christele_r]

Envoyé par sabotage

Pour Mysql (je ne sais pas pour les autres drivers), la préparation est par défaut émulé par soucis de compatibilité avec mysql < 5.1 mais il est possible d'utiliser la préparation du serveur mysql en changeant le paramètre ATTR_EMULATE_PREPARES.

Je n'ais pas contrôlé depuis longtemps, mais par défault j'étais "True" de base

Envoyé par sabotage

mysql_real_escape_string()
pas vraiment moderne : cette fonction existe depuis 11 ans et est maintenant classé comme obsolète à ne plus utiliser.
Quand au fait qu'elle ferrait la même chose que PDO je ne vois pas trop à quoi tu fais référence.

Je fais référence justement a la protection des données tels que je l'ais écris
plus bas.

Envoyé par sabotage

Les accents ne posent pas de problème dans les requêtes et ne sont pas modifiés par mysql_real_escape_string. Ca serait d'ailleurs bien gênant d'avoir des caractères multioctet dans un encodage simple octet non ?

Oui tu as raison Sabotage, mais c'est ce que m'indique mon éditeur hexadécimal
Dans un fichier non UTF8 j'ais bien cela ... mais tu me mets le doute,
c'est peut-étre l'export en *.SQL qui provoque cela ???

Bref tu m'as mis un gros doute sur tout cela, je vais appronfondir ces trois points

A++ et merci
Christele