Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 12/05/2016 13:35:47
- Tetra
- Membre
Migration appli 8.2 vers 9.X [résolu]
Bonjour,
Nous utilisons une "veille" application normalement installée sur Windows XP et PostgreSQL 8.2.
Microsoft ayant annoncé la fin d'XP, notre objectif est de faire tourner cette application sur Windows 7 et/ou 10.
A faire la bascule, nous voudrions en profiter pour passer sur une version plus récente de PostgreSQL.
D'un point de vue système, nous avons bien avancé.
Nous arrivons à lancer l'application sur Windows 7 et 10. Nous testons actuellement avec PostgreSQL 9.5.2 mais avons l'erreur suivante :
ERREUR: l'opérateur n'existe pas : date = integer au caractère 98
Aucun opérateur ne correspond au nom donné et aux types d'arguments.
Vous devez ajouter des conversions explicites de type.
CEST INSTRUCTION : SELECT id_date_fete FROM Fete WHERE ( id_dept_fete =$1 OR id_dept_fete =999 ) AND ( id_date_fete =$2 + 1 )
Je suppose que le problème vient du + 1 sur la date. J'ai vu des posts où ils indiquent qu'il faut créer des casts, ce que j'ai essayé de faire mais sans succès.
Si vous avez des idées ou piste.
2 précisions :
- je n'ai pas le code source de l'application
- mon postgre est installé sous Windows également
Merci
Dernière modification par Tetra (21/05/2016 00:25:23)
Hors ligne
#2 12/05/2016 21:35:11
- rjuju
- Administrateur
Re : Migration appli 8.2 vers 9.X [résolu]
Bonjour,
L'erreur vient en fait de « id_date_fete = $2 ». Êtes-vous sûr des paramètres utilisés ?
Sinon, date + entier marchera sans problème :
# select version();
version
══════════════════════
PostgreSQL 9.5.1...
(1 row)# select current_date = current_date + 1;
?column?
═══════
f
Julien.
https://rjuju.github.io/
Hors ligne
#3 16/05/2016 23:18:37
- Tetra
- Membre
Re : Migration appli 8.2 vers 9.X [résolu]
Re-bonjour,
En fait, je vois dans le log quelques lignes plus haut ceci :
SELECT id_date_fete FROM Fete WHERE ( id_dept_fete =$1 OR id_dept_fete =999 ) AND ( id_date_fete =$2 )
CEST DÉTAIL: paramètres : $1 = '30', $2 = '2015-08-09'
Comme je n'ai pas le code source de l'appli, je me demande si les paramètres sont correctement typés.
Possible que le $2 soit passé en chaîne
Peut-on activer quelque chose au niveau de postgresql pour avoir le type des paramètres dans le log ?
Merci,
Hors ligne
#4 17/05/2016 12:54:06
- rjuju
- Administrateur
Re : Migration appli 8.2 vers 9.X [résolu]
date = '2015-08-09' est tout à fait valide. De plus le message d'erreur indique bien la première requête et non celle-ci.
Une chose m'intrigue cependant:
prepare test as select * from toto where dt = $1 + 1;
PREPARE
prepare test as select * from toto where dt = $1 + 1;
ERROR: operator does not exist: date = integer
LINE 1: prepare test as select * from toto where dt = $1 + 1;
Vous avez donc apparemment un comportement différent de ce qui est attendu en 9.5. Quelle(s) modification(s) avez-vous apportée(s) ? Je suppose qu'il s'agit des cast que vous avez ajoutés.
Julien.
https://rjuju.github.io/
Hors ligne
#5 17/05/2016 22:49:33
- Tetra
- Membre
Re : Migration appli 8.2 vers 9.X [résolu]
Je ne suis pas sûr de comprendre votre dernière remarque.
Dans le premier extrait de log que j'ai donné, j'ai bien le problème d'opérateur que vous citez (date = integer).
Si je comprend bien le log (ce qui n'est pas sûr du tout) je vois une requête sans +1 qui passe et une seconde avec le +1 qui foire.
Revoici le log.
2016-05-10 12:28:32 CEST LOG: exécute _PLAN04CACAE0: SELECT id_date_fete FROM Fete WHERE ( id_dept_fete =$1 OR id_dept_fete =999 ) AND ( id_date_fete =$2 )
2016-05-10 12:28:32 CEST DÉTAIL: paramètres : $1 = '30', $2 = '2015-08-09'
2016-05-10 12:28:32 CEST LOG: instruction : RELEASE _EXEC_SVP_04CACAE0
2016-05-10 12:28:32 CEST LOG: instruction : SAVEPOINT _EXEC_SVP_04CACF70
2016-05-10 12:28:32 CEST LOG: instruction : select n.nspname, c.relname, a.attname, a.atttypid, t.typname, a.attnum, a.attlen, a.atttypmod, a.attnotnull, c.relhasrules, c.relkind, c.oid, pg_get_expr(d.adbin, d.adrelid), case t.typtype when 'd' then t.typbasetype else 0 end, t.typtypmod, c.relhasoids from (((pg_catalog.pg_class c inner join pg_catalog.pg_namespace n on n.oid = c.relnamespace and c.oid = 21363) inner join pg_catalog.pg_attribute a on (not a.attisdropped) and a.attnum > 0 and a.attrelid = c.oid) inner join pg_catalog.pg_type t on t.oid = a.atttypid) left outer join pg_attrdef d on a.atthasdef and d.adrelid = a.attrelid and d.adnum = a.attnum order by n.nspname, c.relname, attnum
2016-05-10 12:28:32 CEST LOG: instruction : RELEASE _EXEC_SVP_04CACF70
2016-05-10 12:28:32 CEST LOG: instruction : SAVEPOINT _per_query_svp_;DEALLOCATE "_PLAN04CACAE0";RELEASE _per_query_svp_
2016-05-10 12:28:32 CEST LOG: instruction : SAVEPOINT _EXEC_SVP_04CACAE0
2016-05-10 12:28:32 CEST ERREUR: l'opérateur n'existe pas : date = integer au caractère 98
2016-05-10 12:28:32 CEST ASTUCE : Aucun opérateur ne correspond au nom donné et aux types d'arguments.
Vous devez ajouter des conversions explicites de type.
2016-05-10 12:28:32 CEST INSTRUCTION : SELECT id_date_fete FROM Fete WHERE ( id_dept_fete =$1 OR id_dept_fete =999 ) AND ( id_date_fete =$2 + 1 )
2016-05-10 12:28:32 CEST LOG: instruction : ROLLBACK to _EXEC_SVP_04CACAE0
Merci encore...
Hors ligne
#6 20/05/2016 00:30:47
- Tetra
- Membre
Re : Migration appli 8.2 vers 9.X [résolu]
Bonsoir,
J'ai fait de nouveaux tests en ne faisant varier que la version de PostgreSQL.
Sur un même OS (VirtualBox Windows 7 64) avec des installations "fraîches" et sans altération de PostgreSQL j'ai les résultats suivants :
Avec la version 8.2.23 (32 bits), aucun problème. Avec l'option log_statement à All j'obtiens :
2016-05-19 21:47:09 LOCATION: exec_simple_query, postgres.c:820
2016-05-19 21:47:09 LOG: 00000: statement: SELECT id_date_fete FROM Fete WHERE ( id_dept_fete =30 OR id_dept_fete =999 ) AND ( id_date_fete ='2015-08-09' ::date + 1 )
2016-05-19 21:47:09 LOCATION: exec_simple_query, postgres.c:820
2016-05-19 21:47:09 LOG: 00000: statement: RELEASE _EXEC_SVP_03D915A8
Avec les versions 9.5.2 et 9.3.13 (64 bits) j'ai l'erreur suivante :
2016-05-20 00:02:23 CEST ERREUR: l'opérateur n'existe pas : date = integer au caractère 98
2016-05-20 00:02:23 CEST ASTUCE : Aucun opérateur ne correspond au nom donné et aux types d'arguments.
Vous devez ajouter des conversions explicites de type.
2016-05-20 00:02:23 CEST INSTRUCTION : SELECT id_date_fete FROM Fete WHERE ( id_dept_fete =$1 OR id_dept_fete =999 ) AND ( id_date_fete =$2 + 1 )
J'ai ensuite joué via pgAdmin la requête SELECT id_date_fete FROM Fete WHERE ( id_dept_fete =30 OR id_dept_fete =999 ) AND ( id_date_fete ='2015-08-09' ::date + 1 ) en 9.3.13 et elle fonctionne.
J'ai réussi à obtenir via pgAdmin la même erreur que l'appli en modifiant la requête ainsi SELECT id_date_fete FROM Fete WHERE ( id_dept_fete =30 OR id_dept_fete =999 ) AND ( id_date_fete =2015-08-09 + 1 )
Je pense que mon problème est en lien avec ce qui est décrit dans cet article http://petereisentraut.blogspot.fr/2008 … resql.html.
Cependant, j'ai essayé d'appliquer le SQL de création des casts mais cela pose d'autres problèmes amont (en gros une erreur qui indique que plusieurs cast implicites sont possibles et que le moteur ne sait pas lequel appliquer).
Merci d'avance pour votre aide.
[Edit]
Un contact m'indique avoir fait tourner l'application en question sur une 9.X mais sous Linux.
Peut-il y avoir des comportements différents entre Linux et Windows pour une même version de PostgreSQL ?
[/Edit]
Dernière modification par Tetra (20/05/2016 00:33:35)
Hors ligne
#7 20/05/2016 11:57:18
- gleu
- Administrateur
Re : Migration appli 8.2 vers 9.X [résolu]
Votre problème est lié au changement de comportement de PostgreSQL depuis la version 8.3. Du coup, vous testez avec une 8.2 et une 9.3 et 9.5, c'est normal que vous ayez des problèmes.
L'information que donne Peter sur son blog est un moyen de se sortir des plus grosses problématiques, mais pas de toutes. Donc il n'est pas forcément étonnant que ça ne suffise pas pour vous. De toute façon, cette "solution" est mauvaise. Il vaut mieux se baser sur le nouveau comportement en corrigeant la requête.
Enfin, concernant les comportements différents entre Linux et Windows, non, il ne doit pas y en avoir. En tout cas pas sur ce genre de problème.
Guillaume.
Hors ligne
#8 21/05/2016 00:09:00
- Tetra
- Membre
Re : Migration appli 8.2 vers 9.X [résolu]
Je pense avoir trouver une solution bien que le fait que cela fonctionne relève d'après moi du miracle.
Je partage quand même avec vous des fois que ça puisse aider quelqu'un.
Ce que j'ai oublié de préciser dans mes posts c'est que l'appli se connecte en ODBC. Du coup quand je vous disais que je ne faisais varier que la version du serveur PostgreSQL ce n'était pas tout à fait juste...en fait je changeais aussi la version des pilotes ODBC pour qu'ils soient en phase avec le serveur.
Du coup, et bien que je sois avec un serveur 9.X, j'ai paramétré les connexions ODBC avec des drivers 8.2. En faisant cela, l'application semble fonctionner. Je dois encore faire des tests pour voir si ça ne bloque pas plus loin même si oui, je sais, c'est bien crado comme solution.
Cependant, comme je n'ai pas accès au code source, je ne peux pas intervenir sur les requêtes pour les rendre conforme 9.X.
Ce que je pense, c'est que le pilote ODBC 8.2 dé-paramètre les requêtes. Ce qui me fait dire çà, c'est qu'avec une telle config, je ne vois plus aucun paramètre dans le log. La fameuse requête en erreur est devenue
SELECT id_date_fete FROM Fete WHERE ( id_dept_fete =30 OR id_dept_fete =999 ) AND ( id_date_fete ='2015-08-09' ::date + 1 )
-- au lieu de SELECT id_date_fete FROM Fete WHERE ( id_dept_fete =$1 OR id_dept_fete =999 ) AND ( id_date_fete =$2 + 1 )
Merci quand même à tous pour votre aide. Partagez avec vous mon problème m'a permis de mieux y réfléchir. En plus, les informations que vous m'avez données notamment sur le comportement des serveurs PostgreSQL Linux/Windows m'ont permis d'éliminer de fausses pistes.
Cordialement,
Hors ligne
Pages : 1