<html> <head> <title>Test odbc></title> </head> <body> <div> <?php $BASENAME = "Test"; $USERNAME = "user"; $PASSWORD = "pass"; print "Tentative de connexion a la base de donnees ".$BASENAME." / ".$USERNAME." / ".$PASSWORD."<br/>"; odbc_close_all(); $cnx = odbc_connect ($BASENAME,$USERNAME,$PASSWORD,SQL_CUR_USE_DRIVER); print "Resultat = ".$cnx."<br/>"; if ( ! $cnx ) { print "Error in odbc_connect to Open Criteria: ".$BASENAME; } else { print "<h2>Connexion reussie au serveur Open Criteria</h2>\n\n"; } odbc_close_all(); ?> </div> </body> </html>
Le résultat:
CODE
Warning: odbc_connect(): SQL error: [Open Criteria Driver] Connexion impossible., SQL state 08004 in SQLConnect in D:\Base\phpodbc.php on line 13
Ma configuration: MS/Windows2000 SP4 FR + patchs IIS 5.0 PHP 4.3.9 Personal Open Criteria 3.7a.1.01 Redirecteur Open Criteria 3.7a.1.01 Driver ODBC Open Criteria 3.71.01.01
Mes recherches: En Open Criteria 3.6.x le même script plantait définitivement le driver ODBC :( Ce n'est plus le cas en version 3.7a.1.01 mais le retour d'erreur est le même... <_< La base de données est bien accessible par d'autres applications (SQL-View, MS/Query, etc.) :angry: Ce script fonctionne sans problème avec une base de données MS/Access ou My-SQL :angry: Pour ce développement je souhaite utiliser prioritairement Open Criteria... :wink: Quelqu'un travaille-t-il déjà avec PHP? Avez-vous déjà rencontré ce type d'erreur? Nota: j'ouvre parallèlement à ce post un ticket à la hotline. Je vous tiendrais informé de la solution (sauf si quelqu'un la connaît déjà) :wink:
coke38, je crois que ce probléme a déjà été signalé içi. La connexion ne fonctionne qu'avec une base de donnée distante, pas locale.
Bonne idée d'essayé d'attaqué une base criteria à travers ODBC en utilisant PHP. Alexandre avait donné un petit exemple de script php pour se connecter sur une base criteria, mais je crois que la base n'était pas en local.
La réponse du support technique m'assure que mon script fonctionne avec easyPhp 1.6 et Criteria 3.6d :(
Cette information est déjà rassurante, mais il me reste toujours à comprendre pourquoi nous avons ce retour de message d'erreur 08004? A quoi correspond-t-il? Pourquoi cela ne fonctionnerait-il pas en PHP standard (sans easyPHP)? :angry:
A ce sujet est-ce que quelqu'un a déjà utilisé easyPHP? Quelle différence par rapport à du PHP standard (connexion aux bases de données par module CGI)? :(
Je sais que ce n'est pas le bon forum pour poster une demande sur PHP, mais mon problème est que cela ne fonctionne pas exclusivement avec Criteria via ODBC, donc si vous avez une quelconque piste, je suis preneur ;)
j'ai fait tourné une version du forum en local sur plusieurs machine en utilisant php easy. Pour voir la différence entre php et easy php faut peut etre aller voir sur le site de easy php ;-)
Une nouvelle version d'easy php est disponible depuis peu, on peut meme l'installer sur une clé usb maintenant.
Pourquoi ne pas tout simplement utiliser ton script avec easy php ? Quelle version de php utilises tu ? As tu essayé sous différents environnement (windows, unix et useit ) ?
Pourquoi ne pas tout simplement utiliser ton script avec easy php ?
Parce que cette application est destinée à un environnement de production et par conséquent, nous voulons maîtriser autant que peux se faire l'environnement d'exécution pour en assurer la maintenance évolutive B)
QUOTE
Quelle version de php utilises tu ?
La réponse se trouve juste au dessus... 4.3.9. :P
QUOTE
As tu essayé sous différents environnement (windows, unix et useit ) ?
Non, seulement sur MS/Windows2000 qui sera l'environnement de production immédiat en attendant un UseIT ou Solaris / Apache, lorsque nous aurons le temps et les compétences de serveur d'applications web adéquats dans ces environnements :)
Cordialement,
This post has been edited by coke38 on 24/03/05 23:02
La réponse du support technique m'assure que mon script fonctionne avec easyPhp 1.6 et Criteria 3.6d :(
Etrange comme réponse de prologue. La réponse inverse aurait été plus logique : cela fonctionne avec php ( le standart ) mais pas avec easy php ( version exotique de php , mais qui fonctionne trés bien à priori ;-) )
Le probléme est peut etre uniquement au niveau du connecteur ODBC qui serait différent antre easy php et php.
Le probléme est peut etre uniquement au niveau du connecteur ODBC qui serait différent antre easy php et php.
Je ne sais pas, mais j'ai pris l'engagement de transmettre au support technique, l'intégralité de ma procédure d'installation, afin qu'il puisse reproduire l'erreur dans les mêmes conditions et me donner une solution :)
Pour information, l'anomalie a été confirmé par Prologue Software :) Elle ne se pose, à priori, qu'avec une version Personal Open Criteria, mais pas avec une version Client-Serveur :wink:
Au passage, cet incident m'a permis de faire une installation EasyPHP 1.8 et vérifier que cela fonctionnait correctement, mais comme je l'ai déjà dit pour l'instant je veux un serveur d'applications web MS/IIS 5.0 et une installation maîtrisée, alors qu'avec EasyPHP il est bien précisé que cet environnement est réservé au développement <_<
A bientôt pour vous informer de la correction, mais en attendant vous pouvez contourner le problème avec une version Client-Serveur, également avec une version pour MS/TSE ou encore peut-être dans un autre environnement de système d'exploitation :rolleyes:
Il n'est jamais trop tard pour apporter une réponse... :lol:
J'ai effectué une nouvelle batterie de tests dans mon contexte décrit ci-dessus et je confirme que le problème est corrigé en version 3.7c D1 :)
En fait, Open Criteria 3.7b D1 (cf. TechnNews):
QUOTE
• L'utilisation de scripts ASP ou PHP sous Windows n'aboutissaient jamais à la connexion au DSN Criteria.
Et Open Criteria 3.7c D1 (cf. TechnNews):
QUOTE
• Les connexions simultanées d'applications WEB au serveur Criteria et leur fonctionnement concurrent sont pris en compte. La gestion des appels multi-thread d'une même connexion n'était pas assurée dans les version précédentes, ce qui pouvait entraîner des conflits de données, des blocages du service ou la rupture de connexion d'un autre utilisateur. Ces appels sont maintenant correctement gérés et le nombre d'accès est traité comme pour les connexions locales, à savoir, un accès par connexion simultanée.
Et bien d'autres améliorations et corrections (L'utilisation des nouvelles DLL Msjet40 pour MS/Access, les connexions simultanées d'applications JDBC (Java), etc.
Bref que du bonheur en attendant l'utilisation prochaine de BD@net :wink:
Cordialement,
Coke
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
www.prologue-community.org n'est pas enregistré à la CNIL www.prologue-community.org est hébergé sur visit.fr
www.prologue-community.org est indépendant de la société Prologue Une grande partie des logiciels et outils cités sur www.prologue-community.org sont des produits et marques déposées par la société Prologue