Bonsoir,

Bien d'accord, j'ai compris mais je signale que de l'information fausse ou devenue fausse circule. Il me parait important de désigner la source, de comprendre et aussi d'expliquer pourquoi.
En effet, une des raisons pour lesquelles je cherche a être assez complet dans l'expression que j'utilise est l'existence des moteurs de recherche qui permettent de trouver des "fils de discussion" qui apportent les liens ou le explications qui nous manquent par ailleurs.

Je vous tiens au courant de la suite et des répercussions (réponses - actions) du coté de dev.TkiWiki.

Cordialement

trebly

pour pdo_mysqli c'est faux, je t'ai expliquer pourquoi plus haut

Bonsoir,
Je rentre d'une véritable expédition en zone inondée frappée par la tempête.

Merci de vos réponses, j'essaye d'être le plus concis possible concis en ne devenant pas abscons (je viens de finit et je ne vois pas comment j'aurais pu un dire moins et rester clair et utile potentiellement à d'autres lecteurs).
par ailleurs l'effort fait pour communiquer force à une réflexion source de clarifications.

Le problème d'origine posé est presque totalement résolu. Il s'agissait d'une fonction PDO non trouvée (setAttribute). Ce problème ne se posait pas dans la version antérieure (3.3) de Tikiwiki qui créait un objet PDO depuis le programme racine et appelait directement toutes les fonctions. Notamment "prepare" retourne un objet de "PDO_statement" (appelé d'ailleurs dans Zend Framework "_stmt" en tant que variable objet $_stmt).
L'analyse de la version 4.1 montre que les auteurs ont implémenté une structure de classe qui pose en fait problème (voir plus loin celle du ZEND Framework). Ce qui est écrit comprend :
[b]Création de classes[/b]
[list]
[*]Une abstract class TikiDb qui permet de gérer une base Tiki, elle comprend l'objet base en private static que l'on stocke et auquel on accède en "singleton" par les fonctions set et get
[*]Une classe tikiDb_PDO extends TikiDb qui permet d'exécuter un certain nombre de fonctions sur un objet déclaré PDO par une instruction : TikiDb::set( new TikiDb_Pdo( $dbTiki ) );[/list]
[b]Une exécution[/b]
[list]
[*]La création de l'objet dbTiki par : "$dbTiki = new PDO("$db_tiki:$db_hoststring;dbname=$dbs_tiki", $user_tiki, $pass_tiki);"
[*]Le surclassement (qui est le problème) de $dbTiki en Tiki_Db_Pdo et son stockage comme singleton dans TikiDb par TikiDb::set( new TikiDb_Pdo( $dbTiki ) );[/list]

C'est ce surclassement qui semble-t-il fonctionne en 3.2 sous linux et ne fonctionne pas en 3.3 sous windows
En effet l'instruction suivante :
TikiDb::get()->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

Produit l'erreur [function "setAttribute" not found]
en effet l'objet crée $dbTiki = new PDO surclassé en TikiDb_Pdo n'a plus accès aux fonctions PDO.

En ajoutant à la classe TikiDb_Pdo une fonction setAttribute qui est une simple interface l'exécution se déroule normalement.
Ensuite on peut ajouter la fonction "prepare" qui retourne un objet PDOStatement correct.

[b]Désolé pour le Pb "execute" et accès à PDO pour PDOStatements : faux problème du aux versions de test[/b]
L'objet PDOStatement retourné par "prepare" est normalement traité par PDO dans le programme racine sans définir une classe Tiki_PDOStatement comme avec ZEND. En effet après analyse plus détaillée de mes modifs, analyse complémentaire faite pour valider mes propos (rédaction en cours de ma réponse), il apparait que j'avais oublié d'effacer un test d'include du PdoStatement de Zend dont la fonction "execute" (instanciation dans ZEND PDOStatement correspondant à la définition d'une interface PDO) et qui, incomplète et présente pour test, masquait celle de PDO.

Si l'exécution ne se termine pas sur une erreur INVALID PDOStatement dans le premier PDOStatement retourné par prepare (16667 c), [b]par contre le problème d'origine est réglé dans son principe.[/b]
[b]
Les conséquences et la cohérence liée[/b]
Comme la classe abstraite TikiDB définit les méthodes Set et Get de la base via une private static (méthode du singleton), à partir du moment où pour exécuter les fonctions PDO énumérées plus haut (setAttribute, getAttribute et prepare) définies maintenant dans la classe TikiDb_Pdo accessible à l'instance TikiDb:get() il faut bien que ces fonctions appliquent les fonctions PDO à l'instance. Alors il faut que TikiDb::get() puisse être utilisé dans une fonction de la classe TikiDb_Pdo qui hérite de la classe TikiDb. Evidemment cela ne passe pas, c'est considéré à juste titre comme un erreur de syntaxe.
Il faut utiliser le nouveau "nom" clef (je préfère à "mot" utilisé dans la doc) apparus en 3.3.x "parent" et on écrira parent::get()->execute(array(''));

Nota: Quand on examine la classe TikiDb_Pdo on voit qu'il existe un doublon "évolutif" du singleton et c'est potentiellement la pagaille. Evidemment sans le nom clef parent cela ne pouvait pas fonctionner.
J'ai donc nettoyé le code pour que la private $db non statique de la classe
TikiDb_Pdo soit une fois créée attribué comme singleton et que seul le singleton soit utilisé.
J'en conclus que lors du développement de la version 4.1 l'équipe TikiWiki a été confrontée à ce problème, et a fonctionné avec 3.2 qui permettait d'accéder à un objet PDO surclassé en TikiDb_Pdo, ce qui ne marche plus de la même manière avec 3.3.x.
Les modifs sont uniquement dans les classes et sont donc rapides à mettre en place.

[b]Conclusion[/b]
Il y a bel et bien masquage des fonctions PDO par le surtypage détaillé plus haut en 3.3.x qui n'existait pas en 3.2 et 3.3 permet grâce à "parent" de traiter le problème dans la définition des classes.
En ajoutant les fonctions utiles à la classe TikiDb_Pdo (setAttribute, GetAttribute, prepare) comme interface vers les fonctions PDO on traite le problème, cela nécessite d'utiliser "parent", sinon point de salut.
Je suis donc maintenant convaincu qu'il s'agit d'un comportement normal de 3.3.x (cela me semble bien dans le sens des mécanismes d'héritage voulus) et 3.2.x acceptait normalement par nécessité une telle séquence donnant accès aux fonctions PDO dns la racine.
Pour sa part l'objet PDOStatement retourné est vu correctement par PDO (extension).
Par contre le statement est cossu et une erreur fatale est générée. La raison est ailleurs, peut-être dans les problèmes de cohérence des instances $db. 3.3 permettant de finir une programmation propre.

Eh bien voilà, j'aurais peut-être très bientôt un version windows (et autre plateformes) de tikiwiki tournant en php3.3 ce qui de toute évidence n'était pas le cas. Je pourrais donc proposer une 4.11.

[b]Merci de me confirmer que mes propos semblent cohérents sous tous leurs aspects.[/b]

Je testerai WampServer sur un serveur qui tourne sous 2000 Server.

Il n'y avait donc pas de problème lié à la configuration globale proprement dite de php et des extensions (sous réserve d'aboutir), mais un sacré problème de "versionning" avec cohérence entre TikiWiki et Php.

Enfin un détail : à propos mysqli_pdo.php, j'avais trouvé cette info dans un document de bonne facture concernant php6 et que j'ai provisoirement égaré, il contenait notamment une liste d'extensions Php6. dont mysqli_pdo.dll

Merci d'avance

trebly

@stealth : je ne sais pas pour toi, mais perso j'aime bien les détails (et je râle bien assez après ceux qui ne prennent pas la peine d'en donner), alors je m'abstiendrai de faire le reproche à trebly d'en faire trop (même si c'est tentant, et peut-être même utile...) ;)

@trebly : ma première réponse était peu utile, résultant d'une lecture en diagonale (mode turbo) de ton problème et je te prie de m'en excuser. Ceci dit, j'ai continué à suivre ton sujet et ses mises à jour (j'ai bien dû le relire cinq fois attentivement) et je doute que ton problème mérite le temps et l'énergie que tu as déjà passé dessus. #-o

Au point où tu en es, si j'étais toi, je jetterais sans hésiter cette config de dev (façon de parler...) et je tenterais une install fraîche de Tikiwiki sur un autre pack WAMP (par exemple [b]wampserver[/b], qu'on apprécie par ici pour sa qualité, sur lequel j'ai plus d'expérience qu'easyphp (particulièrement les versions récentes) et dont je n'ai jamais eu à me plaindre de la configuration par défaut, en particulier concernant mysql/pdo). Si possible sur un windows tout frais (car les fichiers de config résiduels après désinstall pourraient te jouer des tours). Juste histoire de voir si tu rencontres le même souci. :priere:

Ca ne devrait pas te prendre longtemps et ça t'apporterait soit un déblocage, soit des éléments d'explication pour ton souci (au choix, suivant que ça marche ou pas, et si tu décides de garder wampserver ou de continuer l'acharnement sur ta config actuelle). :)

sous php 6 il n'y aura jamais de pdo_mysqli (pour les raisons au dessus), le problème étant que malgré tout le blabla que tu mets nul part tu nous a mis un message d'erreur, a quel niveau ca coince ? quelle est l'erreur ? :wink:

Bonsoir et merci,

J'ai été "offline quelques jours" et je le serais à nouveau à partir de demain soir (1 semaine de déplacement).
Bien d'accord il n'existe pas de "base" mysqli, par contre les différences entre les jeux d'instruction peuvent justifier des dll différentes. Il semble que ce soit le cas de l'extension dans Php6.
php_pdo_mysql supporte que php soit lancé en extension php mysqli ou mysql.

[b]En fait cet axe de recherche sur des anomalies de configuration (problèmes à venir peut-être) s'avère ne pas être le bon.[/b]
[size=150]
[b]Actions et résultats de base[/b][/size]
En améliorant et en affinant les traces, il s'avère que :
TikiWiki crée d'abord l'objet $dbTiki = new PDO(......)
puis plus tard soumet :
TikiDb::set( new TikiDb_Pdo( $dbTiki ) );
On crée donc un objet PDO surclassé par la classe TikiDb_Pdo et donc $dbTiki devient un objet "conservé" par la classe TikiDb_Pdo.
L'objet n'est plus accessible par l'opérateur de portée et donc on pourrait penser que
TikiDb::get()->setAttribute(PDO:....);
TikiDb::get()->getAttribute(PDO:....);
TikiDb::get()->prepare($sql);
permette d'exécuter les fonctions "setAttribute" "getAttribute" et enfin "prepare" de l'objet PDO inclus dans la classe TikiDb_Pdo.

[b]Comme le programme fonctionne correctement sur le site OVH, le question est de savoir pourquoi les fonctions PDO sont invisibles dans mon environnement malgré l'utilisation de l'opérateur de portée.[/b]

A mon avis, soit il s'agit d'une particularité de l'implémentation Windows (douteux), soit une évolution de php dans les accès d'héritages divers statiques et dynamiques car chez OVH la version est une 3.2.x alors que mon installation est en 3.3.1. J'en cherche la confirmation.

[size=150][b]Actions entreprises et conclusions[/b][/size]
J'ai donc entrepris de tester les accès de classes et le problème des portées.
Pour cela j'ai fait appel à mes connaissance de base, à un de mes amis très pointu sur certains sujets et lui vrai professionnel avec qui on peut discuter des "philosophies en matière d'héritages de propriétés et méthodes et leur évolutions dans les différents langages...", et enfin je me suis appuyé sur l'analyse de la structure du Zend workshop. Nota: Zend est inclus en sources dans Tikiwiki 4.1 mais n'est pas connecté... je pouvais chercher....
Ensuite j'ai effectué les test utiles.
Ainsi j'ai implémenté une fonction SetAttibute, GetAttribute et "prepare($sql)" dans la classe TikiDb_Pdo qui fonctionne très bien, je vais donc plus beaucoup plus loin (13700 instructions avant de planter... APACHE ou de terminer volontairement en Exception error). En effet l'instruction
$sth = TikiDb::get()->prepare($qry); // Marche après instanciation dans la classe TikiDb_Pdo de la fonction prepare compatible avec PDO (comme un interface)
par contre
$sth->execute();
évidemment ne passe pas (passe sur OVH php 3.2 mais plante tout sur ma configuration) et comme l'objet retourné est est un pdo_Statement, je n'ai pas trouvé d'autre solution que de faire comme dans Zend, créer une définition d'interface PDO et une instanciation dans un nouvelle classe que j'ai commencé à créer
class TikiDb_Pdo_Statement implements PDO_interface ....
et de déclarer
$sth=new TikiDb_Pdo_Statement

nota: En créant une fonction PDOexecute($sth) dans TikiDb_Pdo on passe le paramètre (statement object) mais on en peut rien en faire, puisque on doit être dans un autre branche, on plante évidemment PHP-APACHE il faut utiliser la classe TikiDb_Pdo_Statement qui comprend l'ensemble de l'interface Statement de PDO.

[size=150][b]En conclusion, à partir d'un problème apparemment anodin supposé de configuration[/b][/size]

il semblerait que la structure de programmation qui passait par une vraie faille (par rapport à la philosophie actuelle en cours de mise en place) par laquelle on passait en php 3.2 n'est plus comptatible avec 3.3.x.
Le problème encore plus grave pour le travail que j'ai engagé est malheureusement que le contact avec l'équipe de développement TikiWiki à laquelle je me suis joint par intérêt pour le produit, est bien difficile et elle est totalement muette sur mes "bugs tracks" (magré mes questions sur le chat je n'ai pas trouvé dans le 400 développeurs qui est compétent sur le sujet, je n'ai trouvé non plus de document sur le développement de l'intégration de Zend).
Pourtant mon problème était simple : avoir une installation de développement qui fonctionne pour m'attaquer à bien d'autres sujets, j'ai tous les outils mais pas une version de TikiWiki compatible... Ce qui m'arrête après quatre mois de mise en route et de mise en place de sites.

Au stade où je suis arrivé, si j'ai bien raison, les modifs à apporter à la version 4.1 (et surtout les test sur de gros produit) me semblent importantes (présence de très nombreuses requêtes qui devront être modifiées (new TikiDb_Pdo_Statement : j'en trouve plus de 10 000) pour faire une version en fait décalée par rapport aux orientations du projet (intégrer Zend et le portage généralisé multibases réparties de plus)... faire donc du travail in fine inutile.
Il me semble être dans une impasse tant qu'une nouvelle version de TikiWiki n'est pas sortie, version au développement de laquelle je n'aurai pas pu participer....

Si je me trompes et si tu as une idée plus simple, merci d'avance.

Désolé pour la longueur de mes mails mais je ne vois pas vraiment ce qui est superflu.

Cordialement

trebly

$mydb=new PDO("mysqli:....  ); 

t'as pas compris ma reponse, ca existe pas les mode mysql et mysqli, c'est l'[b]extension[/b] mysql et l[b]'extension[/b] mysqli et l'[b]extension[/b] PDO avec un pilote (mysql)

donc
[php]$mydb=new PDO("mysqli:.... ); [/php]

ca n'existe pas, aucun SGDB s'appelle "mysqli"

Bonsoir <sthealth> à qui je réponds plus particulièrement mais aussi aux autres lecteurs intéressés par le sujet,

Au delà de la réponse, je fournis ici je pense des éléments de synthèse et une reformulation de la question.

Oui, bien sur, utiliser une configuration complète donne plus de souplesse et de richesse, mais, à mon avis, cela ne change rien au problème de fond :
cf mes messages sur les forums Mysql et easyphp :
[url]http://forums.mysql.com/read.php?11,354940,354940#msg-354940[/url]

[url]http://www.easyphp.org/forums/read.php?16,146561,146561#msg-146561[/url]

[b]Considérations générales, environnement[/b]
En effet, bien entendu, j'ai étendu les extensions suivant la nécessité, c'est la cas de le dire... par exemple en introduisant xdebug. Easyphp est un outil d'installation que j'ai utilisé au début et qui met en place un ensemble cohérent, ensuite, du moins c'est comme cela que je le pratique, je configure et j'étends en fonction des besoins. Etant donné que ce n'est pas mon activité principale mais un outil, et que je cherche à travailler et faire travailler dans des environnements les plus simple possible (limiter les pb d'interactions, compatibilité, paramétrages etc. qui ne posent pas de pb a des équipes spécialisées mais plus difficile pour des moyens limités pluri-disciplinaires) donc plus je simplifie mieux je me portes. C'est quand je me butte aux limites du système installé que j'étends.

[b]Après ces considérations générales, voici les points essentiels à mon sens :[/b]
[list]
[*]Easyphp ne limite pas les extensions en soi, à ma connaissance, il suffit de faire les modifs adaptées de paramètres et déclarations dans php.ini et apache voire my.ini
[*]php_mysql, php_mysqli, sont, nous sommes bien d'accord, des extensions indépendantes. Php_mysql, php_mysqli comprennent les fonctions de connexion et de requêtes directes à MYSQL en mode mysql ou mysqli (différences de fonctions et de syntaxe, mais aussi d'extensions supportées - suivant le(s) mode(s) utilisé par ces extensions). C'est pourquoi la version pleine de MYSQL comporte deux branches d'extension mysql et mysqli.
[*] php_pdo_mysql aussi indépendant des précédent implémente le Php Data Object qui est capable d'attaquer différents serveurs. En particulier nous noterons dans les extensions mysqli (fournies avec easyphp) le support de : MS QL, SYBASE, ORACLE, ODBC (accès ODBC Microsoft), PostgreSQL, SQLite, et enfin MYSQL via les extensions php_pdo _mssql, php_pdo _oci, php_pdo _odbc, php_pdo _pgsql, php_pdo _sqlite et php_pdo _mysql
[*]Où cela se gâte c'est quand les différentes bases évoluent, il faut disposer de l'extension à la fois compatible avec la version de Php et celle de la base utilisée. La cohérence doit être maintenue.
[*]Dans le cas de MYSQL il a en fait deux serveurs qui ne fonctionnent pas tout à fait de la même manière cf : [url]http://dev.mysql.com/doc/[/url] mysql et mysqli et l'on travaille pour accéder à la base dans un mode ou dans l'autre. Pour le cas que je soumets les extensions nécessaires conduisent à utiliser mysqli. Le problème est qu'il semblerait qu'il ne faut pas lire php_pdo_MYSQL (ou MYSQL désignerait la BASE) mais php_pdo_mysql (serveur mysql) et donc on devrait alors trouver une extension php_pdo_mysqli (exécutant les requêtes en mode mysqli). Cette extension existe en php6. [/list]
[b]
En conclusion[/b]
[color=#40BF00][b]La question est : [/b][/color]
[b]est-ce l'extension php_pdo_mysql (php 5.3.1) supporte les modes mysql et mysqli ?
Si oui pourquoi l'intruction
[code]$mydb=new PDO("mysqli:.... ); [/code]
renvoie l'erreur "DRIVER NOT FOUND" [/b]

Cordialement

Trebly

Hello,
deja pourquoi se contenter de easyPHP ? pour débuter c'est bien mais apres..., autant prendre apache sur le site apache et php sur le site php, et la tu pourras mettre les extension que tu veux.

Mysqli c'est juste une class pour mysql ni plus ni moins donc y ni aura jamais de pdo_mysqli, les extensions pour mysql etant : php_mysql, php_mysqli, php_pdo_mysql chacun étant indépendant, (php_pdo_mysql na rien a voir avec php_mysql)

:wink:

Bonjour,

1- <- stealth -> pourquoi ? trop détaillé, trop ésotérique (donc trop court...), trop de phrases ? J'ai bien conscience que mon texte est bien long, mais est-il adapté au problème ? Je n'ai pas de certitudes donc je ne peux affirmer d'où des formules restrictives lourdes etc... D'autre part la vérification est longue et difficile à cause du nombre de paramètres entrant en jeu. Et je ne dispose pas (plus) d'une équipe pour comparer le comportement sur plusieurs configurations. Je ne peux que compter sur les forum. Et pour l'instant les résultats sont pauvres (ic phpFrance, dev Mysql, easyPhp, developpez.com)

2- <- Calimero -> non pas d'accord les bibliothèques concernent uniquement la conversion des syntaxes d'accès en mode interprété à partir de php. Elles permettent de convertir un programme php faisant appel au serveur en mode mysql en programme contenant des instruction de connexion et requêtes mysqli, on convertit des commandes myql<->mysqli directes.
Ici comme l'on appelle directement en mode objet l'extension PDO ($mydb=new PDO("server":"database", "user", "passwd");
C'est à dire : "php_pdo_mysql.dll", puisque php_pdo.dll n'existe plus en configuration php 5.3.0) c'est elle qui, soit comprend et gère un appel avec un nom de serveur "mysql" alors que le serveur est mysqli (php extension = mysqli défini reconnu comme tel par MYSQL - affiché par phpmyadmin) et versus si l'extension est "mysqli" l'extension prendra en charge (exécutera) des requêtes mysqli ou effectuera des requête mysql si le serveur MYSQL s'annonce en mode mysql. Or actuellement tout se passe comme si l'extension "php_pdo_mysql.dll" ne prenait en charge que l'extension mysql (annonce "serveur non trouvé" si l'on précise mysqli, et renvoie un objet NULL si le server nomme est mysql quand MYSQL fonctionne en mode mysqli).
Ce qui veut dire que la confusion potentielle entre le nom de la base "MYSQL" et le nom de "serveur" [en:server] indique que dans le nom de la dll "mysql" ("php_pdo_mysql.dll") est un nom de serveur et nom le nom de base de données, puisque MYSQL fonctionne en mode mysql ou mysqli, deux serveurs voisins mais différents...
Le fait qui abonde dans mon interprétation est que PHP6 comprend une extension php_pdo_[b]mysqli[/b].dll qui n'existe pas en php 5.3.0

[b]Comme je l'ai précisé dans mon texte d'origine il est possible, voire probable, que ce problème-phénomène ne se produise que pour la version Windows avec une installation EasyPhp 5.3.0[/b]

Actuellement statu quo

Cordialement, merci de votre aide

Trebly

Merci pour le résumé détaillé ;)

Il te suffirait d'une bilbiothèque de compatibilité mysql<->mysqli... ça se trouve sur le web (et ça peut se faire soi-même aussi).

tu sors de Master ?

Bonjour,

Désolé pour la longueur mais j'expose ici un problème qui m'a déjà couté 100h de travail

[size=150][b]Résumé[/b][/size]
Je n'arrive pas a effectuer une installation de TikiWiki 4.1 qui utilise Php orienté objet dans un environnement Windows "au top". Le problème semble venir de la prise en compte non assurée par PDO du serveur mysqli de cette installation EasyPhp 5.3.0.
[list]
[*]Il semblerait que avec Easyphp 5.3.0 (Windows) seule l'extension php mysqli soit supportée (Serveur mysql = mysqli) ce qui serait assez normal, mais peut perdre certaines applications écrites pour le serveur d'extension php mysql.

[*]Corrélativement l'objet PDO défini par l'extension associée "php_pdo_mysql.dll" ne semble pas supporter pas mysqli (New PDO(mysqli:...) retourner l'erreur "DRIVER non TROUVE".

[*]la dll d'extension "php_pdo_mysql.dll" serait donc purement php extension=mysql ce qui rendrait toute connexion mysqli impossible et générateur des anomalies citées dans le détail de ce texte.

[*]Comme je n'ai rien trouvé de concret sur ce sujet, il a peut être une erreur de nature différente dans mon installation et une manière d'accéder au serveur mysqli via l'extension "php_pdo_mysql.dll" pour laquelle je n'ai pas trouvé de documentation.

[*]Indépendamment mais consécutivement, en tout état de cause, le fait qu'une création [b]"new PDO" [/b]sur un [b]serveur mysql:[/b]... (avec un PHP.INI définissant l'extension "php_pdo_mysql.dll" retourne un objet NULL sans erreur n'est pas normal. Les applis que j'installe (Tikiwiki) ne testant pas immédiatement l'objet retourné mais faisant totalement confiance à la gestion d'erreur, le retour d'un objet NULL n'étant pas une erreur et constituant un cas ne pouvant être gérée en PDOExeption, produit un crash "en quenouille" des applications, singulièrement difficile à trouver quand on a pas encore des outils suffisants. [/list]

[size=150][b]Circonstances :[/b][/size]
J'utilise et commence à participer au développement de TikiWiki.
L'installation chez OVH (mysql5-4.240 et php extension mysql) en version 3.3 puis l'upgrade en version 4.1 se sont passées comme une lettre à la poste (mieux encore). La version 4.1 nécessite PHP5 et utilise PDO et est totalement orientée objet, il était prévu que cette version aille au delà avec ADODB (mais la connexion n'a pas été terminée).
Cette installation réalisée directement chez OVH est très bien supportée avec php 5.2.? et MYSQL5-4.240 sous Linux a fonctionné immédiatement (le temps du FTP (9500 fichiers)).
Par contre tout développement est impossible parce que j'utilise un hébergement mutualisé.
J'ai donc commencé la mise en place sur ma machine qui tourne actuellement sous win XP SP3 avec Easyphp 5.3.0. et pour développer TikiWiki j'ai installé SVN (serveur) et Xdebug enfin Eclipse. Je tourne avec Apache, php et Mysql depuis près de 4 ans et j'ai réalisé les upgrades régulièrement.

[size=150][b]Configuration actuelle du système Windows XP SP3[/b] [/size]
* Serveur: MySQL host info: localhost via TCP/IP
* Version du serveur: 5.1.37-community-log
* Version du protocole: 10
* Utilisateur: root@localhost
* Jeu de caractères pour MySQL: UTF-8 Unicode (utf8)
Serveur web
* Apache/2.2.13 (Win32) DAV/2 mod_ssl/2.2.13 OpenSSL/0.9.8k SVN/1.6.6 PHP/5.3.0
* Version du client MySQL: mysqlnd 5.0.5-dev - 081106 - $Revision: 1.3.2.27 $
* Extension PHP: mysqli
phpMyAdmin
* Version: 3.2.1

[size=150][b]Problème(s) rencontrés après configuration Apache et php adaptée[/b][/size]
PhpMyAdmin permet d'accéder parfaitement ainsi que mes sites Joomla (1.1.15) et mes propres applis, mais elle n'utilisent pas PDO.
[list]
[*]Installation vierge de TikiWiki échoue en quenouille (des erreurs mal gérées ? , qui n'arrêtent pas l'appli...)

[*] Le transfert (pratiqué plusieurs fois en version antérieure de Tiki, utilisant connect mysql) consiste à tranférer la base en SQL depuis l'environnement Linux et utiliser le patch (qq pb avec .htaccess) et la config pour les adresses locales lui abouti à deux issues possibles (après test) :

[*]Lors de la création de l'objet PDO $mydb=New PDO( param1, param2, pram3) [b] (sachant que l'environnement Easyphp semble bien obligatoirement en serveur MYSQL mysqli (php extension = mysqli))[/b] si param1 appelle le serveur "mysqli:.... on génère l'erreur "Driver absent" l'objet erreur (que l'on peut dumper avec xdebug dans le traitement d'erreur (try {....} catch( PDOException $e ) {var_dump($e) etc.} étant correct dans son contenu.

[*]La création d'objet PDO avec le serveur "mysql:...." retourne toujours un objet NULL. Là il semblerait bien qu'il y ait une belle anomalie qaund le serveur MYSQL est mysqli. en effet l'objet retourné est toujours NULL sans erreur signalée. Comme ce retour de PDO n'est pas prévu par Tikiwiki le crash intervient plus loin lors du "session_start()" qui évidemment ne va pas trouver à un moment une procédure ( dans l'open et un "singleton" pattern)
[size=85]nota : je n'ai pas trouvé encore de doc assez précise sur PDO et je n'ai pas assez développé en C++ pour ne pas un peu... user le soleil pour chercher, d'où mon appel à l'aide, car j'ai déja 100h dans les bottes sur cette installation[/size][/list]

[b]Conclusion[/b]
Cette situation me parait résulter d'une absence de support du serveur mysqli "théoriquement assuré" par l' [extension=php_pdo_mysql.dll] alors que l'on attendrait trouver une extension "php_pdo_mysqli.dll" dans php/ext.
Il est à noter que la doc Mysql dernière version précise qu'en version pleine on doit trouver, pour les extensions, deux répertoires : php/ext/mysql et php/ext/mysqli. Par conséquent Easyphp5.3.0 semble présenter une version purement mysqli ce qui est parfaitement logique. Par contre la dll PDO associée est-elle à jour ou en manque-t-il une ?
Il est évident que dans l'environnement Linux d'OVH (mutualisé) ça marche [size=85](quoique le niveau ne soit pas 5.3 mais encore 5.2 et les entry sont bien modifiées et que le produit ait bien évolué de 5.2 à 5.3).[/size]

[color=#00BF00][size=150]A l'aide[/size][/color], mon travail est totalement arrêté depuis près de trois semaines sur ce problème.

Merci d'avance

trebly