Vous n'êtes pas identifié(e).
OK, Merci gleu
J'arrive pas à lancer pgAdminIII version 1.12.2.
L'installation se passe sans erreur mais quand je le lance il m'affiche le message suivant :
cette application n'a pas pu démarrer car la configuration de l'application est incorecte. réinstaller l'application pourrait résoudre le problème.
J'ai réinstaller l'application mais sans succcès
Quelqu'un a déjà rencontré ce genre de problème ?
Pour l'information j'essaie de l'installer sur winXP.
Après avoir réussi de faire le "streaming replication" entre deux serveurs 64bits qui ont un système linux Centos de 64bits aussi, j'essaie maintenant de faire le "streaming replication" entre deux serveurs de 64bits qui ont un système linux Centos mais sur le master c'est un Centos de 64bits et sur le slave c'est un Centos de 32bits.
Après la configuration des deux serveurs pour le "streaming replication" le serveur master démarre correctement par contre le serveur slave ne démarre pas et m'affiche le message suivant dans le fichier de log pgstartup.log
FATAL : somme de contrôle incorrecte dans le fichier de contrôle
Pourriez vous me dire ce qui se passe exactement ?
Merci bcp Marc Cousin
Je voudrai juste savoir si postgreSQL offre cette possibilité de se connecter au master pour un certain temps et au moment que nous choisissons nous même (chaque deux heures par exemple) et non pas au démarrage du service postgres seulement
Est ce que c'est possible de configurer le serveur esclave de postgreSQL pour qu'il se connecte en "streaming replication" au serveur maître toute les deux heures par exemple pour l'éviter d'être surcharger tout le temps ?
Merci d'avance
Bonsoir,
Un grand merci à vous deux pour votre aide précieuse.
Bonjour à tous,
Merci pour vos réponse.
D'accord, je commence à mieux cerner, et pour davantage comprendre ce mécanisme imaginons la situation suivante :
Le Maitre crée le fichier archive wal (disons) 19.
Mais il se passe un problème de connexion, et le serveur esclave ne récupère pas ce fichier 19 (mais celui-ci est archivé sur le répertoire d'archive du serveur maitre).
Arrive le checkpoint et le fichier 19 est supprimé du répertoire de log (de travail).
Entre temps, bien entendu le maitre a créée des autres fichiers wal (20, 21, ...).
Que se passe t-il lorsque le serveur esclave réussit à se reconnecter au serveur maitre ?
Du fait que le fichier 19 est absent, le serveur esclave reste t-il en attente du fichier 19 et n'exploite pas les autres fichiers wal suivant (20, 21,...) ?
Doit il impérativement récupérer le fichier 19 et le traiter (donc par ce mécanisme de restore) pour continuer le process de réplication ?
Et toujours à propos du mécanisme, ayant paramétré un répertoire d'archivage sur le serveur maitre (et pour poursuivre avec l'exemple ci-dessus), le serveur maitre après le rétablissement de la connexion avec le serveur esclave, sachant que ce dernier attend le fichier wal 19, ne peut il pas aller chercher dans son répertoire d'archive (au moins, faire la tentative de recherche) ce fichier wal 19, sachant qu'il sait où se trouve à priori son répertoire d'archive (de par le paramètre "archive_command") ?
Doit t-on donc aller récupérer à la main le fichier 19 et le mettre dans le répertoire restore alors que le serveur maitre peut très bien aller le récupérer (dés le rétablissement de la connexion) dans son répertoire d'archive et servir le serveur esclave qui lui demande ce fichier dans sa séquence de réplication.
PS à Marc Cousin : j'imagine que le recovery_command dont vous parlez est le restore_command, non ?
Merci pour votre réponse
La réplication passe par ces fichiers. À partir de la 9.0, en utilisant la Streaming Replication, la réplication passe en plus par un protocole réseau spécifique.
Vous avez besoin de ce paramètre en cas de coupure de la liaison de réplication ou si l'esclave accuse un lag trop important.
Cela veut dire qu'avec la version 9.0, la réplication en mode "normal" s'effectue par le protocole réseau (communication entre le maitre et l'esclave).
Dans ce cas, si je comprends bien, le paramètre "restore_command" ne sert à rien.
C'est dans le cas d'une coupure de liaison que ce paramètre sert, mais cela veut dire que nous aurions été copié ces fichiers "à la main" du répertoire d'archivage du maitre vers le répertoire d'archivage de l'esclave, c'est en quelque sorte un mode de fonctionnement en secours ?
A travers la documentation que j'ai lu, je n'ai pas très bien compris également la notion de lag que vous mentionnez ici, et son impact précis (comme ce cas que vous mentionnez "en cas de lag trop important" de l'esclave, c'est un aspect encore confus pour moi).
En tout cas, merci pour votre aide.
J'aimerais avant toute chose remercier Marc Cousin pour toute l'aide utile qu'il a pu m'apporter.
Je progresse dans la mise en place de la réplication entre 2 serveurs, et je m'interrogeais au sujet d'un paramètre ("restore_command").
On trouve un paragraphe dans le documentation postgresql ici :
http://docs.postgresql.fr/9.0/recovery-config.html
Et le passage est le suivant :
restore_command
La commande d'interpréteur à exécuter pour récupérer un segment de la série de fichiers WAL archivés. Ce paramètre est nécessaire pour la récupération à partir de l'archive, mais optionnel pour la réplication à flux continu. Tout %f dans la chaîne est remplacé par le nom du fichier à récupérer de l'archive, et tout %p est remplacé par le chemin de destination de la copie sur le serveur. (Le chemin est relatif au répertoire courant de travail, c'est à dire le répertoire de données de l'instance.) Tout %r est remplacé par le nom du fichier contenant le dernier point de reprise (restartpoint) valide. Autrement dit, le fichier le plus ancien qui doit être gardé pour permettre à la récupération d'être redémarrable. Cette information peut donc être utilisée pour tronquer l'archive au strict minimum nécessaire pour permettre de reprendre la restauration en cours. %r n'est typiquement utilisé que dans des configurations de warn-standby. (voir Section 25.2, « Serveurs de Standby par transfert de journaux »). Écrivez %% pour inclure un vrai caractère %.Il est important que la commande ne retourne un code retour égal à zéro que si elle réussit. La commande recevra des demandes concernant des fichiers n'existant pas dans l'archive; elle doit avoir un code retour différent de zéro dans ce cas.
Par exemple:
restore_command = 'cp /mnt/server/archivedir/%f "%p"'
restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
Je ne comprends pas bien ces explications.
J'ai parcouru ce tutorial ici :
http://www.dalibo.org/_media/replicatio … ql_9.0.pdf
Et ce tutorial évoque notamment, dans le cadre du streaming replication, pour le serveur esclave, l'utilisation de ce paramètre.
Si je fais le parallèle avec le paramètre "archive_command" au niveau du serveur maitre, je comprends que le archive_command effectue une copie des fichiers wal, dans un répertoire de son choix, afin d'archiver précisément les fichiers wal.
Mais côté serveur esclave, les fichiers wal (ou les modifications sur le serveur maitre) sont transmises via le protocol de communication entre les 2 serveurs, et donc à quoi sert en fait ce restore_command ??
J'aurais compris, qu'à l'image du serveur maitre, on puisse aussi avoir une copie des fichiers wal, du répertoire des journaux vers un répertoire de notre choix, mais le restore_command indique qu'il s'agit d'une copie dans l'autre sens : d'un répertoire d'archive vers le répertoire de travail de postgres.
Or à quoi cela sert il, puisque les informations transitent dans la communication entre les 2 serveurs et non pas par l'intermédiaire des fichiers d'archive.
Je ne comprends pas du tout à quoi sert ce paramètre, et d'ailleurs quand je ne le met pas dans le fichier de config, la réplication marche quand même, mais je m'interroge sur ce paramètre car je le vois un peu partout dans les exemples, dans le cadre de la mise en place d'un streaming replication.
Par avance, merci à celui qui pourra m'éclairer sur ce point.
@gleu
Dans la commande archive_command, il y a un le paramètre "cp" qui permet de faire la copie des fichiers d'archives vers une destination que ce soit en local ou sur un autre serveur, je l'ai testé et ça marche nickel
Pour passer en hot_standby est ce que cela va surcharger la machine Slave par des connexions provenant du Master pour que le Slave soit quasi identique au Master ou bien le hot_standby et le streaming replication auront la même charge sauf que le hot_standby offre la possibilité de la lecture seule.
C'est quoi vraiment la différence entre ces deux mode au niveau de l'impact sur le serveur Slave ?
Je viens de mettre en place la réplication en mode (SR) Streaming replication mais j'ai un problème au niveau de la récupération des fichiers archivés au niveau du serveur Master par le serveur Slave.
J'explique au niveau du serveur Master il exécute bien la commande suivante :
archive_command = 'cp %p /var/lib/pgsql/9.0/data/pg_wal/%f'
pour copier le fichier journal du répertoire /var/lib/pgsql/9.0/data/pg_xlog vers le répertoire en local /var/lib/pgsql/9.0/data/pg_wal que j'ai créé.
Par contre le serveur Slave ne récupère pas les fichiers journaux du Master pour les rejouer (restaurer) avec la commande suivante :
restore_command = 'cp /var/lib/pgsql/9.0/data/pg_wal/%f "%p"'
Même si je prends les fichiers archivés par le master et les mettre dans le répertoire /var/lib/pgsql/9.0/data/pg_wal du Slave en vu de restaurer ces fichiers mais il ne le fait pas.
Voici ce que j'ai dans les logs du serveur Slave :
LOG: le système de bases de données a été arrيté ـ 2011-03-23 13:34:47 CET
LOG: lancement du processus autovacuum
LOG: le système de bases de données est prيt pour accepter les connexions
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=57416
LOG: le système de bases de données a été interrompu ; dernier lancement connu ـ 2011-03-23 14:13:50 CET
LOG: entre en mode standby
cp: ne peut évaluer `/var/lib/pgsql/9.0/data/pg_wal/000000010000000200000019': Aucun fichier ou répertoire de ce type
LOG: enregistrement de longueur nulle ـ 2/19000078
cp: ne peut évaluer `/var/lib/pgsql/9.0/data/pg_wal/000000010000000200000019': Aucun fichier ou répertoire de ce type
LOG: réplication de flux connecté avec succès au serveur principal
Sachant que le fichier 000000010000000200000019 existe sur le master et n'a pas été récupéré par le slave et même après une récupération manuelle de ma part de ce fichier archivé au niveau du master vers le slave, ce dernier n'a pas restaurer le fichier archivé en question.
Autre chose je n'arrive pas à accéder à la dase du serveur slave, j'ai le message d'erreur suivant : FATAL : le système de base de données se lance.
Normalement je ne doit pas avoir ce message parce que d'après la documentation à partir de la version 9.0 on peut accéder à la base du slave en lecture seule.
Merci de m'aider à débloquer cette situation.
Effectivement, il fallait vider le répertoire DATA de postgreSQL du serveur en attente (Slave) avant de faire la synchronisation des deux répertoires DATA entre le serveur principal et le serveur en attente
Maintenant j'ai plus le message d'erreur concernant les identifiant des deux bases de données.
Je te montre aussi les logs des deux serveurs :
Serveur principal (Master)
**********************
LOG: le système de base de données est arrêté
LOG: le système de bases de donnىes a ىtى arrيtى ـ 2011-03-23 12:08:44 CET
LOG: lancement du processus autovacuum
LOG: le système de bases de donnىes est prيt pour accepter les connexions
LOG: connexion de réplication autorisىe : utilisateur=postgres, base de données=192.168.10.2, port=45385
Serveur en attente (Slave)
**********************
LOG: le système de bases de données est prêt pour accepter les connexions
LOG: le système de bases de données a été interrompu ; dernier lancement connu ـ 2011-03-23 12:10:07 CET
LOG: entre en mode standby
cp: ne peut évaluer `/var/lib/pgsql/9.0/data/pg_wal/000000010000000200000015': Aucun fichier ou répertoire de ce type
LOG: enregistrement de longueur nulle ـ 2/15000078
cp: ne peut évaluer `/var/lib/pgsql/9.0/data/pg_wal/000000010000000200000015': Aucun fichier ou répertoire de ce type
LOG: réplication de flux connecté avec succès au serveur principal
LOG: la ré-exécution commence ـ 2/15000078
LOG: état de restauration cohérent atteint ـ 2/16000000
Merci Bcp
Non je n'ai rien supprimé comme fichiers
J'ai synchronisé les deux bases de données avec les commandes suivantes que j'ai lancé au niveau du serveur principal :
/usr/bin/psql -c "SELECT pg_start_backup('label', true)"
rsync -a -v -e ssh /var/lib/pgsql/9.0/data/ 192.168.10.2:/var/lib/pgsql/9.0/data/ --exclude postmaster.pid --exclude postgresql.conf --exclude pg_hba.conf
/usr/bin/psql -c "SELECT pg_stop_backup()"
Après cette synchronisation, j'ai vérifié les deux bases de données et ils étaient identiques
Bonjour,
Pour faire la réplication (streaming replication) entre deux bases de données postgresql9.0 sur deux serveurs de 64bits, j'ai configuré le serveur principal et le serveur en attente de la manière suivante :
1) Serveur principal (Master)
Dans le fichier postgresql.conf :
**************************
listen_addresses = '*'
wal_level = archive
archive_mode = on
archive_command = 'cp %p /var/lib/pgsql/9.0/data/pg_wal/%f'
max_wal_senders = 5
wal_keep_segments = 32
Dans le fichier pg_hba.conf :
************************
host replication postgres 0.0.0.0 0.0.0.0 trust
Et j'ai configuré aussi le serveur en attente de cette façon :
2) Serveur en attente (Slave)
Dans le fichier recovrey.conf :
*************************
standby_mode = 'on'
primary_conninfo = 'host=94.23.240.208 port=5432 user=postgres'
restore_command = 'cp /var/lib/pgsql/9.0/data/pg_wal/%f "%p"'
Après avoir synchronisé les deux répertoires DATA (/var/lib/pgsql/9.0/data/) de postgresql9.0 entre les deux serveurs (Master/Slave) et relancé les services de postgresql9.0, j'ai eu le message suivant dans les logs du serveur en attente par contre les logs du serveur principal montre que tout est OK :
Log du serveur en attente
*********************
FATAL: l'identifiant du systوme de bases de donnىes diffوre entre le serveur principal
et le serveur en attente
DةTAIL: L'identifiant du serveur principal est 5580278574645196799, l'identifiant du serveur en attente
est 5586543497412834231.
cp: ne peut ىvaluer `/var/lib/pgsql/9.0/data/pg_wal/00000001000000030000009D': Aucun fichier ou rىpertoire de ce type
cp: ne peut ىvaluer `/var/lib/pgsql/9.0/data/pg_wal/00000001000000030000009D': Aucun fichier ou rىpertoire de ce type
Log du serveur principal
********************
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36419
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36420
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36421
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36422
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36423
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36424
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36425
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36426
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36427
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36430
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36431
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36432
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36433
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36434
LOG: connexion de réplication autorisée : utilisateur=postgres, base de données=192.168.10.2, port=36435
Merci pour vos réponse je suis rassuré maintenant
Bonjour,
Après vérification sur la source du waring que j'ai annoncé précédemment dont je rappel son contenu c'était à cause de l'espace disque qui a atteint le 100% :
le message d'erreur :
.
.
.
pg_restore: setting owner and privileges for INDEX index_associe
pg_restore: setting owner and privileges for INDEX index_bilan2_bilid
pg_restore: setting owner and privileges for INDEX index_bilid
pg_restore: setting owner and privileges for INDEX index_dirigeant
pg_restore: setting owner and privileges for INDEX index_entreprise
pg_restore: setting owner and privileges for INDEX index_historique_dirigeant
pg_restore: setting owner and privileges for INDEX index_historique_entreprise
pg_restore: setting owner and privileges for INDEX index_mvt_associe
pg_restore: setting owner and privileges for INDEX index_photo_associe
pg_restore: setting owner and privileges for INDEX index_photo_dirigeant
pg_restore: setting owner and privileges for INDEX index_photo_entreprise
pg_restore: setting owner and privileges for INDEX index_ratios_sectoriel
pg_restore: setting owner and privileges for FK CONSTRAINT F_REFERENCE_ANNONC
pg_restore: setting owner and privileges for FK CONSTRAINT fkey
WARNING: errors ignored on restore: 269
Bref, après l’augmentation de l’espace disque de la partition /var j'ai retapé la même commande c'est à dire :
/usr/local/pgsql/bin/pg_restore -i -h aixserver -p 5432 -U toto -d mabase -v "/var/prog/13Octobre2009.backup"
Et la restauration s'est bien passé sans aucun problème ou message d'erreur.
Ma seule remarque c'était pourquoi je n'avais pas un message à la fin de la restauration me disant que : PostgreSQL database restore complete par exemple
Ce que j'avais à la fin de la restauration c'est le prompt # comme suite :
pg_restore: setting owner and privileges for INDEX index_photo_associe
pg_restore: setting owner and privileges for INDEX index_photo_dirigeant
pg_restore: setting owner and privileges for INDEX index_photo_entreprise
pg_restore: setting owner and privileges for INDEX index_ratios_sectoriel
pg_restore: setting owner and privileges for FK CONSTRAINT F_REFERENCE_ANNONC
pg_restore: setting owner and privileges for FK CONSTRAINT fkey
#
#
Je me suis dis que peut être ils avaient des messages d'erreurs mais postgres les a camouflé et c'est par la suite que j'ai relancé une autre restauration avec pg_restore en ajoutant l'option -e comme "Marc Cousin" m'a demandé de faire pour afficher les messages d'erreurs
Voici la commande pg_restore que j'ai utilisé:
/usr/local/pgsql/bin/pg_restore -i -e -h aixserver -p 5432 -U toto -d mabase -v "/var/prog/13Octobre2009.backup"
La restauration s'est bien passé sans aucun problème ou message d'erreur avec l'affichage du prompt # à la fin de la restauration.
Et pour me rassurer encore plus j'ai fait un dump (sauvegarde) de la base que je viens de restaurer pour voir si tout se passera bien avec la commande suivante :
/usr/local/pgsql/bin/pg_dump -i -h aixserver -p 5432 -U postgres -F c -b -v mabase > /var/prog/21Octobre2009AIX.backup
Le dump aussi s'est bien passé sans erreurs avec l'affichage du prompt # à la fin du dump comme suite :
pg_dump: dumping contents of table ufs
pg_dump: dumping contents of table uniforme
pg_dump: dumping contents of table utilisateur
pg_dump: dumping contents of table visiteur
pg_dump: dumping contents of table client
#
#
Ma question est ce que c'est normale que le pg_dump et pg_restore n'affichent pas les message de fin de traitement c'est à dire :
PostgreSQL database restore complete
ou
PostgreSQL database dump complete ?
Si se sont des ALTER mais je n'ai pas tout noté, tout ce que j'ai noté c'est ça :
--
-- Name: fkey; Type: FK CONSTRAINT; Schema: schema; Owner: toto
--
ALTER TABLE ONLY trace_correction_detail
ADD CONSTRAINT fkey FOREIGN KEY (tc_id) REFERENCES trace_correction(tc_id);
--
-- Name: public; Type: ACL; Schema: -; Owner: toto
--
REVOKE ALL ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON SCHEMA public FROM postgres;
GRANT ALL ON SCHEMA public TO postgres;
GRANT ALL ON SCHEMA public TO PUBLIC;
--
-- PostgreSQL database dump complete
--
Je viens de lancer une autre commande pg_restore comme suite et j'ai eu le message d'erreur suivant:
/usr/local/pgsql/bin/pg_restore -i -h aixserver -p 5432 -U toto -d mabase -v "/var/prog/13Octobre2009.backup"
le message d'erreur :
.
.
.
pg_restore: setting owner and privileges for INDEX index_associe
pg_restore: setting owner and privileges for INDEX index_bilan2_bilid
pg_restore: setting owner and privileges for INDEX index_bilid
pg_restore: setting owner and privileges for INDEX index_dirigeant
pg_restore: setting owner and privileges for INDEX index_entreprise
pg_restore: setting owner and privileges for INDEX index_historique_dirigeant
pg_restore: setting owner and privileges for INDEX index_historique_entreprise
pg_restore: setting owner and privileges for INDEX index_mvt_associe
pg_restore: setting owner and privileges for INDEX index_photo_associe
pg_restore: setting owner and privileges for INDEX index_photo_dirigeant
pg_restore: setting owner and privileges for INDEX index_photo_entreprise
pg_restore: setting owner and privileges for INDEX index_ratios_sectoriel
pg_restore: setting owner and privileges for FK CONSTRAINT F_REFERENCE_ANNONC
pg_restore: setting owner and privileges for FK CONSTRAINT fkey
WARNING: errors ignored on restore: 269
Merci d'avance pour ton soutien
J'ai lancé le pg_restore de cette façon :
/usr/local/pgsql/bin/pg_restore /var/prog/13Octobre2009.backup -d mabase -U toto
et à la fin de la restauration qui a pris beaucoup de temps j'ai ce message :
--
-- Name: public; Type: ACL; Schema: -; Owner: toto
--
REVOKE ALL ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON SCHEMA public FROM postgres;
GRANT ALL ON SCHEMA public TO postgres;
GRANT ALL ON SCHEMA public TO PUBLIC;
--
-- PostgreSQL database dump complete
--
Ma question pourquoi j'ai lancé la commande pg_restore et à la fin j'ai un message comme si j'ai lancé un dump, sachant que ma base n'a pas été restauré ?
Le fichier 13Octobre2009.backup a été généré par PgAdminIII sous windows.
Sous PgAdminIII j'ai fait bouton droit sur ma base de donnée puis sauvegarder
Bonjour,
Merci "Marc Cousin" pour votre réponse.
Voici le message d'erreur que j'ai eu quand je lance le restore à partir de psql :
psql:/var/prog/13Octobre2009.backup:5906: invalid command \}¤Op^w,8@/eًiأُك=B(َيصخ@~ع'Gب,ٍ5ْP؛ٌ~M|uِض
psql:/var/prog/13Octobre2009.backup:5911: \q: extra argument "َن؛" ignored
psql:/var/prog/13Octobre2009.backup:5911: ERROR: invalid byte sequence for encoding "UTF8": 0xaa
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
Que dois je faire par la suite svp ?
--------------------------------------------------------------------------------
Bonjour,
Merci les ami(e)s pour vos réponses, j'espère que cela ne me posera pas de problème par la suite.
Bonjour,
J'ai fait un dump (sauvegarde) d'une base de donnée postgres sous linux Centos et j'ai essayé de la restaurer sous la machine AIX 5.3 mais sans succès, voici comment j'ai procédé :
1) Avec PgAdmin.
Restauration de la base postgres sous aix avec l'utilitaire PgAdmin :
-> Après 4heures de la procédure de restauration le programme PgAdmin plante
2) Avec Webmin
Restauration de la base de donnée postgres sous aix avec l'interface d'administration Webmin déjà installé sous AIX.
->Après 1heure de la procédure de restauration j'ai eu le message d'erreur suivant :
Encodage de forme spécifique de donnée attendu mais obtention d'un encodage normal
S'il vous plaît quelqu'un peut me dire ce que cela veut dire ?
Sachant que l'encodage de ma base de donnée est en UTF-8.
Voici l'encoding de mes machines Linux et AIX :
Linux:
# locale
LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=
AIX:
# locale
LANG=FR_FR.UTF-8
LC_COLLATE="FR_FR.UTF-8"
LC_CTYPE="FR_FR.UTF-8"
LC_MONETARY="FR_FR.UTF-8"
LC_NUMERIC="FR_FR.UTF-8"
LC_TIME="FR_FR.UTF-8"
LC_MESSAGES="FR_FR.UTF-8"
LC_ALL=FR_FR.UTF-8
Merci
