Vous n'êtes pas identifié(e).
En utilisant un "mauvais" encodage client on peut avoir cette erreur :
postgres=# show client_encoding;
client_encoding
-----------------
utf8
(1 ligne)
postgres=# show server_encoding;
server_encoding
-----------------
UTF8
(1 ligne)
postgres=# CREATE TABLE test_accent (
postgres(# Nom VARCHAR(50),
postgres(# Prénom VARCHAR(50)
postgres(# );
ERREUR: séquence d'octets invalide pour l'encodage « UTF8 » : 0xe96e6f
postgres=#
Mais ce n'est pas une solution (si un caractère win1252 correspond à un encodage UTF8, ça passera...)
Attendons ce que donnent les tests de Marc...
Ce n'est probablement pas de l'UTF8 : si vous l'avez créé en ligne de commande sur la console Windows, je pense que c'est du CP1252.
J'ai déjà eu le même souci...
La solution est peut-être d'interdire de créer les tables ainsi - obliger à passer par pgAdmin, par exemple?
Point de vue de développeur :
1°) Quand on vient d'Oracle, on n'est pas perdu (tous les développeurs que j'ai vu y passer, y compris moi, y passent très rapidement)
Très bonne documentation (on s'y retrouve bien plus rapidement que dans celle d'Oracle, il n'y a pas d'informations contradictoires, elle est tenue à jour en même temps que le code.
Il y a plein de trucs sympa pour le développeur, comme generate_series, le type serial... On gagne du temps sur le développement de test notamment.
On peut l'installer sur les postes de travail (là également, en développement, cela peut faire gagner énormément de temps).
Les ordres DDL sont transactionnels (très pratique si un problème se produit lors d'un script de mise à jour de schéma).
La communauté est très active (voir les mailing-lists du projet, la communauté française est petite par rapport à l'ensemble)
Inconvénients :
Certains outils propriétaires ne gèrent pas encore PostgreSQL (outils comme LoadRunner, outils de modélisation...)
2°) Marc a répondu
3°)idem
4°) Je dirai aussi qu'on n'a pas de surprises... PostgreSQL fait ce qu'on attend d'une base de données. Pas de troncature de données dans votre dos, pas de choses louches. Si la donnée ne respecte pas le type, c'est une erreur. Ce n'est pas le cas avec MySQL. Et on a de vraies séquences...
5°) rien à ajouter.
j'avais déjà mis le log_min_duration-statement qui donne pas mal de renseignement sur le temps de réponse.
A quoi correspond : 0.276957 user 0.210967 sys total c'est du temps cpu consommé par l'user et le temps cpu consommé par le systàme/
et comment interpreter la ligne : #011!#0110.000028 elapsed 0.000000 user 0.000000 system sec
Merci de votre aide
A+
Gilbert
Je suppose que user et system font référence aux modes d'exécution :
http://stackoverflow.com/questions/5564 … t-of-time1
(Que quelqu'un m'arrête si je dis des âneries!)
Je suppose donc que
0.000028 elapsed 0.000000 user 0.000000 system sec
c'est 0.000028 en temps passé, mais 0 en temps CPU pour le processus en mode utilisateur, et 0 dans le noyau.
Je ne sais par contre pas à quoi correspond la ligne entourée par des crochets. Avez-vous cherché dans la documentation de PostgreSQL??
voici ce qe j'ai fiat:
state.executeUpdate("INSERT INTO salle (id_salle, nom_salle, type_salle) VALUES (1, '"Csalle"','"TSalle"' )");
au faite il fallait mettre '" "' au tour de chaque variable pour que psql le considere come une variable au lieu d'une constante.Merci d'avance.
Ce ne doit pas être ce que vous avez fait : la syntaxe n'est pas correcte. Je suppose que vous avez concaténé les chaînes?
De toute manière, pour des raisons de sécurité, il vaut toujours mieux préparer la requête et utiliser les variables comme expliqué dans le document proposé par Marc :
par exemple (je suppose que cSalle est un int, tSalle une String)
state.executeUpdate("INSERT INTO salle (id_salle, nom_salle, type_salle) VALUES (1, ?,? )");
state.setInt(1,cSalle);
state.setString(2,tSalle);
Tu pourrais alors nous donner la définition de quelques tables, qu'on comprenne ton problème?
J'ai du mal à saisir si vous avez déjà créé vos tables (t_adresse, t_codepostal, etc...), et si votre problème est que vous ne savez pas concevoir votre base, ou que vous ne savez pas écrire les requêtes pour l'utiliser?
Si j'ai bien compris, votre problème est d'ailleurs vaste (trop vaste). Vous cherchez à résoudre le problème général du mapping entité - relationnel, pour lequel il n'y a pas une bonne solution. Il y a par contre des solutions, avec chacune leurs inconvénients et avantages.
Dites-nous en plus!
Évidemment il n'y a aucune clé étrangère dans l'application.
Là je ne comprends pas. Qu'est-ce que cela a d'évident? Une base sans clé étrangère, ce n'est pas une base, c'est un tas de trucs. Où peut-être vous demandez-vous comment les placer?
Nous avons choisi ce style de solution également, au final (sauf qu'on n'a pas le droit non plus de faire du PL, donc on modifie toutes les requêtes pour ajouter le translate.
J'ai dit ça au client (de passer en 8.4), mais ça ne l'a pas fait rire 
Moi ça ne me fait pas rire non plus au passage (ce n'est vraiment pas facile à faire en php, au point que j'ai trouvé le conseil de le faire faire... par la base de données...). Et même avec une solution, c'est sans compter la masse de travail (quasiment tous les tableaux à refaire).
On est obligés de rester en 8.3.
Bon, tant pis. Merci pour la confirmation (je me doutais de la réponse )
J'ai une base PostgreSQL 8.3, sous Linux (RHEL 5).
On me demande de faire un tri insensible à la casse. Mais le cluster a été créé avec une locale C.
=# SHOW LC_COLLATE;
lc_collate
------------
C
(1 ligne)
=# SHOW LC_CTYPE;
lc_ctype
----------
C
(1 ligne)Donc si je trie une table de cette manière, les accents sont placés à la fin :
select col1, col2 from testtri order by upper(col2)
;
col2
--------
ARBR
ARBRE
arbre
ARBRI
Epi
Zinzin
È
É
Épi
Ê
è
é
épi
ê
(14 lignes)Hors les utilisateurs veulent un ordre de tri français (donc "é" avant "Zinzin").
D'après la doc (http://docs.postgresqlfr.org/8.3/charset.html) on ne peut pas modifier les ordres de tri une fois le cluster créé.
Y a-t-il tout de même une solution autre que recréér le cluster (c'est pour une application déjà en production)
?
Merci.
Ah, oui je viens de me rappeler que tu es en Californie. Bon courage pour le décalage horaire, et profite bien du voyage 
Ah, merci à tous, c'est bon!
C'est mon collègue qui va être content
J'ai fait la requête suivante :
select * from n_code_pays order by libelle='FRANCE', libelle;
Mais cela ramène tous les pays dans l'ordre alphabétique du libellé, sauf la FRANCE.
Bonjour,
On m'a demandé comment, dans une requête, faire un tri sur une colonne, suivant un ordre de tri "non naturel".
Dans notre cas, on a une table avec des noms de pays, et on veut trier suivant le nom de pays, MAIS on met la ligne avec le nom FRANCE en premier.
Il me semble bien avoir déjà vu passer une question du même type, mais vraiment impossible de remettre la main dessus en faisant des recherches...
Je suppose que si le pool de connexion de Tomcat est en JDBC3, vous avez intérêt à ne pas y toucher. Quand au driver, le JDBC3 fera certainement l'affaire, le JDBC4 devrait juste apporter des méthodes supplémentaires. Mais, à vrai dire, ce n'est pas très clair pour moi non plus (pourquoi ils conseillent de prendre le driver JDBC4 à partir de la JVM 1.6?).
Peut-être devriez-vous rechercher, voire poser la question sur la mailing list du driver (on ne sait jamais...) : http://archives.postgresql.org/pgsql-jdbc/
ou peut-être sur le site de Tomcat?
Bonjour,
Je voudrais bien vous aider, mais j'ai bien du mal à comprendre ce que demande Tomcat.
Tomcat6 fonctionne avec quelle JVM? (j'ai cherché un peu mais j'ai pas envie d'y passer la nuit )
En fait, je dirais que c'est simple : si Tomcat 6 est en JVM 1.5, alors JDBC 3.
Sinon, il vaut mieux ouvrir un nouveau fil de discussion pour une nouvelle question.
3 questions (je sais c'est un peu lourd mais on ne sait jamais) :
1: avez-vous rebooté avant de retenter l'installation de postgresql 9.0?
2: est-ce bien l'installeur 32 bits que vous avez pris?
3 : Sinon, avez-vous lu le guide de l'installeur sur http://www.enterprisedb.com/learning/pginst_guide.do
???
Si vous ne trouvez toujours pas, à la fin du guide il y a un lien vers les forums d'EnterpriseDB, mais avant , vous devriez peut-être voir le fichier de log dans %TEMP% (cf le guide dont le lien est ci-dessus), et noter très précisément le message d'erreur au complet (j'ai vaguement le souvenir qu'il y a autre chose dans le message)
Sinon, de mon côté j'ai installé sur XP, mais en service pack 2, il se peut qu'il y ait des différences...
Si cela ne fonctionne toujours pas, essayez toujours de rebooter. Quand j'ai installé PostgreSQL 9.0 sur XP, la 1ère et la 2ème fois j'ai eu une erreur de ce genre "la mémoire ne peut pas être read". Mais après avoir rebooté cela a fonctionné.
(soupir...)
J'ai installé PostgreSQL 9.0 sous Windows XP avec le one-click Installer (l'autre installeur n'existe plus apparemment).
Avec cet installeur, on ne peut pas choisir l'encodage de la console utilisée par le script lancé par le menu démarrer (il reste égal à l'encodage par défaut, soit le CP 850 pour mon XP en Français). Évidemment, ce n'est pas terrible, et psql nous prévient :
Attention : l'encodage console (850) diffère de l'encodage Windows (1252).
Les caractères 8 bits peuvent ne pas fonctionner correctement.
Voir la section « Notes aux utilisateurs de Windows » de la page
référence de psql pour les détails.
Le seul moyen que j'ai trouvé pour remettre le client en encodage WIN1252, c'est de modifier le fichier C:\Program Files\PostgreSQL\9.0\scripts\runpsql.bat en ajoutant la ligne :
chcp 1252avant le lancement de psql.
J'ai noté ici cette remarque, pour le cas où d'autres personnes se poseraient la question (et comme pense-bête pour moi). A moins que l'un d'entre vous ait une manière plus propre de résoudre le problème?
Sinon, comme précisé dans le message d'avertissement, il expliqué dans la documentation comment lancer psql en ligne de commande sous Windows en modifiant l'encodage de la console.
http://docs.postgresql.fr/9.0/app-psql.html#id5160240
Et comme solution temporaire, créer un trigger avant l'insertion pour convertir les chaines vides en null? C'est certes lourd, mais cela permettrait de ne pas modifier la structure des données, en attendant la correction des requêtes. S'il n'est vraiment pas envisageable de les mettre à jour tout de suite...
Evidemment, il faut espérer dans ce cas qu'il n'y ait pas de grosses opérations de mises à jour ou d'insertion, sinon je suppose que les performances risqueraient de s'en ressentir.
Marc, t'en penses quoi?
Ce ne serait pas l'espace entre "Program" et "Files" le problème???
Entourez le chemin avec des guillemets doubles, cela devrait aller mieux...
psql –f "C:\Program Files\PostgreSQL\8.2\share\contrib\lwpostgis.sql" -h localhost -U postgres
C'est simple alors, il te faut l'intersection des 2 ensembles, pour obtenir les object_id qui ont une valeur de filtre_value_id égale à 2 ET une valeur égale à 3.
Une solution :
SELECT object_id
FROM good_filtre
WHERE filtre_value_id = 2
INTERSECT
SELECT object_id
FROM good_filtre
WHERE filtre_value_id = 3
Bonjour,
Pourquoi pensez-vous que c'est le serveur de base de données qui pose problème? (vu les éléments, cela me semble certainement pas la première hypothèse à envisager, mais je ne connais pas votre application.)
Où est la partie métier de votre application (en local? sur le même serveur que la base de données? Sur un autre serveur chez OVH???)
Comment récupérez-vous les 700 images au niveau de l'application? (une par une ou par un seul select?)
Flo
Bien, ça y est, j'ai l'explication :
La doc française n'est pas à jour par rapport à la doc anglaise sur l'exemple en question.
Dans la doc française il y a :
FOR referrer_key IN SELECT * FROM cs_referrer_keys ORDER BY try_order LOOP
et dans l'anglaise :
FOR referrer_key IN referrer_keys LOOP
Ma première tentative :
(j'ai juste remplacé la déclaration du curseur)
CREATE OR REPLACE FUNCTION cs_update_referrer_type_proc() RETURNS void AS $func$
DECLARE
referrer_keys CURSOR IS
SELECT * FROM cs_referrer_keys
ORDER BY try_order;
func_body text;
func_cmd text;
BEGIN
func_body := 'BEGIN' ;
FOR referrer_key IN SELECT * FROM cs_referrer_keys ORDER BY try_order LOOP
func_body := func_body ||
' IF v_' || referrer_key.kind
|| ' LIKE ' || quote_literal(referrer_key.key_string)
|| ' THEN RETURN ' || quote_literal(referrer_key.referrer_type)
|| '; END IF;' ;
END LOOP;
func_body := func_body || ' RETURN NULL; END;';
func_cmd :=
'CREATE OR REPLACE FUNCTION cs_find_referrer_type(v_host varchar,
v_domain varchar,
v_url varchar)
RETURNS varchar AS '
|| quote_literal(func_body)
|| ' LANGUAGE plpgsql;' ;
EXECUTE func_cmd;
END;
$func$ LANGUAGE plpgsql;
Et le message :
ERREUR: la variable d'une boucle sur des lignes doit être une variable de type
RECORD ou ROW, ou encore une liste de variables scalaires
LINE 11: FOR referrer_key IN SELECT * FROM cs_referrer_keys ORDER...
^
Donc j'ai modifié le FOR :
FOR referrer_key IN referrer_keys LOOP
Je vais de ce pas voir ton patch dans l'historique de la mailing-list...
PS : c'est sur une version 9.0 beta 3