Vous n'êtes pas identifié(e).
Pages : 1
Merci pour ces précisions.
J'ai choisi d'appliquer le paramètre sur la base car comme je n'ai pas la maîtrise complète de l'ensemble des triggers je me dis que ça me permet d'approcher le plus possible le fonctionnement d'une version 8.2.
En toute logique, ce ne devrait pas affecter les performances des autres bases hébergées par le même moteur.
Merci Marc, vous aviez vu juste, c'est bien un problème de bytea_output.
En fait, je tente de faire fonctionner une appli conçue pour une version 8.2 sur une 9.4, cf. mon précédent post.
Or, le paramètre bytea_ouput est d'après ce que j'ai lu apparu en 9.
J'ai fixé le paramètre au niveau de la base (ALTER DATABASE mabase SET bytea_output='escape') et ainsi ça fonctionne.
Merci
Bonjour,
J'utilise une appli qui s'appuie sur une BDD dont une fonction trigger fait appel à la fonction decode.
Suivant la source de déclenchement du trigger, la fonction me retourne un résultat sous une forme différente sans que je sache expliquer pourquoi.
Pour mettre cela en évidence, j'ai modifié la fonction pour ajouter une ligne dans un table de log...le trigger ressemble à çà :
CREATE OR REPLACE FUNCTION update_utilisateur()
RETURNS trigger AS
$BODY$declare
(...)
tempvar varchar(50);
BEGIN
(...)
select decode('Ym9uam91cg==','base64') INTO tempvar;
insert into log (log) values (tempvar);
(...)
END;$BODY$
LANGUAGE plpgsql VOLATILE
COST 100;Lorsque je modifie un utilisateur via l'application (connectée en ODBC), je vois dans le log PostgreSQL la requête suivante :
UPDATE utilisateur SET nom_utilisateur = 'depuisapp' WHERE nom_utilisateur IS NULL AND id_utilisateur = 18 AND pwd IS NULLJe joue ensuite via pgAdmin la requête suivante :
UPDATE ctx_02.utilisateur SET nom_utilisateur = 'depuispgadmin' WHERE nom_utilisateur = 'depuisapp'Suite à çà, le requête select * from log me retourne
1 - "\x626f6e6a6f7572"
2 - "bonjour"
Je suppose qu'en 1 ça correspond à "bonjour" en hexa mais qu'est ce qui peut expliquer cette différence ?
Idéalement, je voudrais toujours avoir le résultat tel que 2.
Merci,
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,
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]
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...
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,
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
Pages : 1