Vous n'êtes pas identifié(e).
Bonjour,
j'ai finalement retenu un serveur dédié virtuel chez PHPNET : une solution à 14€ HT/mois facilement configurable. J'utilise déjà avec satisfaction leur hébergement PHP/MySQL mutualisé depuis plusieurs années. J'attendais un peu de recul pour présenter cette solution... sachant que je n'ai pas d'actions chez PHPNET... et que les premiers tests sont tout à fait satisfaisants.
Sur la Squeeze, le "deb_http://backports.debian.org/debian-backports squeeze-backports main" avait été ajouté à la sources.list sans que je demande quoi que ce soit alors que j'avais simplement précisé que j'allais utiliser une version 9.1 de PostgreSQL. Un bon début donc. J'ai basculé quelques bases MySQL sur le serveur PostgreSQL : on "attaque" les bases de l'extérieur aussi bien de mes programmes compilés que de sites PHP hébergés... chez mon autre hébergeur. Bref, c'est une solution à étudier pour ceux qui cherchent un hébergement PostgreSQL.
Merci pour votre aide. Gilles
Bonjour,
Mon hébergeur actuel ne fait malheureusement que du mySQL. Mon hébergement mutualisé présente un énorme avantage, enfin 2 :
1. on peut atteindre les bases autrement que par localhost autrement dit par exemple par un back-office développé en Lazarus ou en C++
2. et de plus, le nombre de connexions simultanées n'est pas limité.
Je cherche les mêmes caractéristiques pour un hébergement mutualisé PostgreSQL. OVH par exemple ne fait pas : on ne peut atteindre la base que par un site de l'hébergement mutualisé (donc en localhost).
Merci. Cordialement. Gilles
Bonjour, donc voici le CR
Installation avec succès à partir de postgresql-9.1.5-1-windows.exe sur un Windows 7 "propre".
J'ai utilisé la ligne de commande suivante :
postgresql-9.1.5-1-windows.exe --unattendedmodeui minimal --mode unattended --servicename "postgreSQL" --servicepassword "pass123456" --superpassword "pass123" --create_shortcuts "0" --datadir "C:\TestDir\PostgreSQL\9.1\data" --locale "French, France"
Plusieurs remarques :
1. postgresql-9.1.5-1-windows.exe --help permet de disposer de toutes les options (notamment par défaut)
2. le fichier install.bat qui contient la ligne de commande et postgresql-9.1.5-1-windows.exe peuvent être stockés sur un support en lecture seule (CD-ROM). L'ensemble nécessite moins de 50 Mo. J'ai placé les 2 dans le même répertoire
3. l'installation nécessite environ 3 minutes et est entièrement automatique
4. j'ai essayé initialement un --locale "fr_FR.UTF-8". Lors de l'installation un message d'erreur indique le problème et stoppe l'installation
5. le programme d'installation crée tous les répertoires nécessaires notamment dans mon cas le datadir.
6. par défaut le --prefix est C:\Program File (x86)\PostgreSQL\9.1. On y retrouve le sous-dossier bin qui contient notamment l'exécutable de pgadmin
7. si --create_shortcuts "0", alors en effet aucun icône sinon les icônes figurent dans "Tous les programmes -> PostgreSQL dont pgADMIN - Aucun sur le bureau.
8. le service est lancé à la fin de l'installation mais il est nécessaire de rebooter sinon "Server doesn't listen : For security reasons, PostgreSQL does not listen on all available IP addresses on the service machine initially
9. dans mon cas, je suis parti de la configuration initiale du PC reformaté avec un seul utilisateur Test sans mot de passe : pas de problème de droit.
10. il n'est pas possible de réaliser une installation alors que PostgreSQL est déjà installé avec la même méthode : un message d'erreur incompréhensible apparaît pendant quelques secondes et la procédure est automatiquement interrompue. Il faudrait faire une analyse plus fine à ce sujet. Deux versions différentes, deux ports différents...
Questions complémentaires :
a. Quelle est l'utilité d'un --servicepassword alors que par défaut le code de l'administrateur de la machine est utilisé ?
b. C'est curieux ce format de --locale. Cela correspond à quelque chose de standardisé ?
c. Je ne sais pas si le programme de désinstallation fonctionne complètement ou plus exactement s'il est compatible avec une ré-installation par le même procédé
Encore merci pour votre aide.
Cordialement. Gilles
Bonjour,
Marc, j'en en effet lu ce type d'installation. La remarque de Julien est encore d'actualité : beaucoup de tentatives font appel à la modification de la base de registre et semble-t-il, ces modifications varient d'une version à l'autre de Windows. Voilà pourquoi de prime abord j'ai écarté cette solution. J'ai récupéré un appareil avec restauration d'image usine de l'OS (Win 7) par F11 à partir du Bios... Cela va me permettre d'essayer de nombreuses combinaisons à partir d'un appareil systématiquement neuf... Car actuellement, au fil des tentatives, je ne suis pas sûr du tout de retourner à une configuration d'origine... "surchargeant" peut-être ainsi les erreurs. Je ferai un CR à l'issue de mes tentatives. Merci pour votre aide.
Cordialement. Gilles
Bonjour,
je cherche une méthode d'installation fiable de pgSQL 9.1 en ligne de commande sous Windows 7 et Windows 2008 (32 et 64 bits).
A partir d'une version 8, j'ai essayé la méthode conseillée sur ce site : msiexec /i postgresql-8.0.0-rc1-int.msi /qr INTERNALLAUNCH=1 ADDLOCAL=server,psql,docs SERVICEDOMAIN="%COMPUTERNAME%" [...] En vain d'ailleurs. J'ai commencé par une 8 parce que je dipose d'un serveur 2003 où j'ai installé proprement mais pas en ligne de commande une version 8. Je pensais comparer à l'arrivée les 2 installations. Peine perdue !
De plus, j'ai découvert fortuitement qu'avec la version 9, il semblerait que la méthode ait changé. Mais visiblement, il a quelques problèmes.
Dans la mesure où chaque tentative terminée par un échec nécessite un nettoyage difficile, quelqu'un pourrait-il m'indiquer une procédure fiable pour une 9.1 ?
D'avance merci. Cordialement. Gilles
Bonjour,
Désolé pour le retard de ma réponse... J'avais d'autres priorités et surtout je n'imagine pas les tests à réaliser. Que faudrait-il tester exactement ? Dans la mesure où il ne semble pas y avoir d'autre alternative en postgreSQL au ON DUPLICATE KEY de mySQL, il ne semble pas possible de faire une comparaison entre 2 solutions postgreSQL. Comparer sur 2 bases "identiques", l'une en postgreSQL, l'autre en mySQL serait pour le moins "subjectif". L'environnement rendrait le test non significatif : tout dépend des paramétrages des serveurs, des moteurs utilisés...
Cordialement. Gilles
Bonjour,
Merci à tous deux.
J'ai adapté (et adopté) la solution proposée par Guillaume. Cela fonctionne parfaitement.
Cordialement. Gilles
Bonjour,
Euhhhh... Avec le recul puis le réveil... normalement pas de confusion... mais à la fin, en désespoir de cause, on essaye tout et n'importe quoi. J'ai essayé initialement avec une procédure stockée de manière classique avec un appel de la forme EXECUTE PROCEDURE xxxx() mais je n'arrive pas à y gérer les injections (dans la procédure d'appel) qui est ma méthode de travail habituelle.
Donc, après beaucoup d'essais infructueux, je me suis demandé s'il existait une méthode SIMPLE bâtie comme une requête avec injection sur le mode d'une "espèce" de procédure stockée puisqu'en pgSQL, il semble que cela soit le seul chemin possible... et je dois reconnaître que pour faire un simple ON DUPLICATE... UPDATE, cela me paraît d'une complexité invraisemblable. Aussi invraisemblable que la requête proposée, certainement... Mais entre invraisemblances...
J'apprécie pour plein de raisons pgSQL mais enfin... je dois reconnaître également que même si un spécialiste me vantera toutes les qualités des procédures stockées, être obligé d'en faire une parce qu'on ne peut pas faire un ON DUPLICATE... UPDATE en requête directe, c'est très perfectible "pour le meilleur SGDBR du monde"... comme le fait de pouvoir créer des colonnes à l'endroit où l'on veut dans une table.
Donc je continue à chercher une solution même si le problème est réglé par mon langage de développement en 2 requêtes (1 SELECT puis selon le cas un INSERT ou 1 UPDATE), non pas seulement par curiosité mais parce que cela me semble un moyen significatif de me permettre d'évaluer plus finement pgSQL. Je retourne à ma doc.
Merci pour votre aide.
Cordialement. Gilles
Bojour,
j'ai beaucoup de mal à comprendre le remplacement de l'inexistant 'ON DUPLICATE KEY UPDATE' de mySQL.
Au départ la requête est celle-ci : 'INSERT INTO myTABLE (xxID, siID, tvTABLE, tvVERSION, xxUSER, xxPOSTE, xxSTAMP) VALUES (:paxxID, :pasiID, :patvTABLE, :patvVERSION, :paxxUSER, :paxxPOSTE, :paxxSTAMP) ON DUPLICATE KEY UPDATE tvVERSION = :patvVERSION, xxUSER = :paxxUSER, xxPOSTE = :paxxPOSTE, xxSTAMP = :paxxSTAMP;
J'ai lu quelque chose qui me semblait simple mais dont je n'arrive pas à faire fonctionner à partir de mon langage (Lazarus) :
BEGIN;
EXECUTE '';
EXCEPTION when unique_violation THEN
EXECUTE 'la requête UPDATE';
END;
Ce qui ferait
BEGIN;
EXECUTE 'INSERT INTO myTABLE (xxID, siID, tvTABLE, tvVERSION, xxUSER, xxPOSTE, xxSTAMP) VALUES (:paxxID, :pasiID, :patvTABLE, :patvVERSION, :paxxUSER, :paxxPOSTE, :paxxSTAMP);';
EXCEPTION when unique_violation THEN
EXECUTE 'UPDATE myTABLE SET tvVERSION = :patvVERSION, xxUSER = :paxxUSER, 'xxPOSTE = :paxxPOSTE, xxSTAMP = :paxxSTAMP WHERE (siID = :pasiID) AND (tvTABLE = :patvTABLE);';
END;
[Dans myTable CONSTRAINT mt_TableVersion UNIQUE(tvTABLE, tvVERSION)]
J'espère que la première syntaxe est exacte. Je n'ai pas pu vérifier car dans la seconde, je me heurte à un premier problème : le fait que les 2 requêtes (INS et UPD) soient quotées génère une erreur au niveau de l'injection... Les paramètres :paxxx sont cachés.
Un avis sur la question ? Une autre approche ?...
...sachant que d'une manière je devrais remplacer des ON DUPLICATE KEY UPDATE et que dans ce cas particulier, j'ai besoin d'un indicateur qui me permette de déterminer si la table a été modifiée depuis ma dernière consultation. Peut-être en postgreSQL, existe-t-il, pour chaque table, un indicateur qui est modifié à chaque DEL, INS, UPD de la dite table...
Sachant également que ce n'est pas un problème crucial : Actuellement avec Lazarus, sur la base postgreSQL,un dataset effectue un SELECT : si "isEmpty" alors le Dataset effectue un INSERT sinon un UPDATE... mais je préférerais progresser un peu en postgreSQL...
Merci. Gilles
Merci pour les réponses.
Bonne fin de WE.
Cordialement. Gilles
Bonjour,
Question 1 : Dans une table "familles" je voudrais savoir s'il est nécessaire/judicieux/redondant de créer un index [CREATE INDEX fm_siID_ik on familles (siID);]... alors que ce champ "siID" est déclaré comme clef étrangère dans le même fichier [CONSTRAINT sf_siID_exist FOREIGN KEY (siID) REFERENCES sites (xxID) ON DELETE CASCADE ON UPDATE CASCADE);] ?
Question 2 : Ce type de déclaration provoque une erreur :
CREATE TABLE familles1 (
xxID char(20),
CONSTRAINT fm_xxID_pk PRIMARY KEY(xxID));
CREATE TABLE familles2 (
xxID char(20),
CONSTRAINT fm_xxID_pk PRIMARY KEY(xxID));
Le nom de la PRIMARY KEY est dupliqué... et dans la BASE, il doit être unique. Autrement dit, on ne peut pas mettre plusieurs fois " fm_xxID_pk " dans plusieurs tables différentes d'une même base. (RQ : je n'ai pas essayé sur 2 bases différentes). Il faut donc nommer la première par exemple fm_xxID_pk1 et la seconde fm_xxID_pk2.
Mais si on écrit,
CREATE TABLE familles1 (xxID char(20) PRIMARY KEY);
CREATE TABLE familles2 (xxID char(20) PRIMARY KEY);
cela passe sans problème. Cette écriture serait-elle alors conseillée par soucis de simplicité ? Et présente-t-elle des différences de fonctionnement avec la première écriture ?
Question 3 : Je suppose que dans tous les cas, lorsqu'on déclare une PRIMARY KEY, il est inutile de déclarer un INDEX sur le champ en question... Est-le cas ?
Merci. Cordialement.
Gilles
En effet,
cela fonctionne très bien.
Merci beaucoup Dverite.
Cordialement. Gilles
Dans mon cas, c'est "un peu" important. Les 3 ou 4 dernières colonnes de chaque table sont traitées automatiquement par Lazarus (xxPANNE, xxUSER, xxPOSTE, xxSTAMP). Mes routines vont chercher directement les 4 dernières colonnes.
J'apprécie peu pour l'instant les divers produits que j'ai rencontrés pour gérer les tables sous pgSQL... surtout comparés à ceux disponibles pour mySQL. Ces "limitations" -qui n'en sont pas vraiment en réalité- expliquent certainement cela. Donc, pour cette histoire de déplacement des colonnes, j'ai réalisé un petit utilitaire pour pouvoir corriger mes tables (avec création d'une table temporaire en effet)... Cela à l'air de fonctionner. Je l'améliore un peu et le mettrai à dispo " en l'état" avec le code source (s'il y a des Pascaliens...).
Donc je considère ce problème mineur réglé. Pour le reste je suis satisfait : sur des tables importantes avec des contraintes fortes, des verrous & co, des procédures stockées, des LIMITs, des OFFSETs, le tout fonctionnant à distance (ie par Internet), j'obtiens un fonctionnement en terme d'utilisation de nos bases similaire à celui de mySQL implanté sur le même serveur. Je dois reconnaître qu'à ce niveau, ayant essayé il y a 3 ans, j'avais plus qu'un doute.
Cordialement. Gilles
Non, pas de problème au dernier niveau évoqué. Je n'ai pas le temps de vérifier les diverses possibilités mais il me semble que certains messages d'erreur diffèrent selon l'utilisation de -h ou --host.... quand il y a mauvaise écriture. Par contre de mauvaises habitudes par "facilité" --host = 192.168.0.30 (qui est l'adresse de la station locale ne passe pas). Il faut évidemment utiliser --host = 127.0.0.1.
Je regarderai cela plus tard. Pour l'instant, cela me convient très bien. L'ensemble est efficace. Il ne faut pas espérer en quelques jours maîtriser toutes les subtilités...
Merci pour votre aide. Gilles
Je précise mon impeccable : en une ligne cela ne passe pas chez moi. Donc je l'ai fait en 2 étapes.
chcp 1252
set PSQL="G:\Wamp\PostgreSQL\bin"
%PSQL%\pg_dumpall -h 192.168.0.15 | psql -h 127.0.0.1 postgres >> provoque une erreur :psql: la connexion au serveur a été coupée de façon inattendue Le serveur s'est peut-être arrêté anormalement avant ou durant le
traitement de la requête."
Pas bien grave... Donc à la place :
chcp 1252
set PSQL="G:\Wamp\PostgreSQL\bin"
%PSQL%\pg_dumpall --host=192.168.0.15 --username=postgres > c:\sa
ve.sql
Puis
%PSQL%\psql --host=127.0.0.1 --username=postgres < c:\save.sql
Cordialement. Gilles
Bonjour,
ADD COLUMN AFTER n'existe pas en pgSQL ? Comment fait-on alors ?
Merci. Gilles
Bonjour,
Impeccable... Merci!
Gilles
Bonjour,
1. Un PostgreSQL "tout neuf" est installé sur un serveur A (Windows 2008 server avec son interface graphique).
2 Sur le serveur A, je crée les rôles, tables issues de mon environnement mySQL.
3. J'installe un serveur PostgreSQL B (même version -"tout neuf et donc vide") sur un serveur Debian (sans interface graphique).
Est-il possible de synchroniser simplement à ce stade (une fois pour l'instant) le serveur PostgreSQL B avec le serveur A... en ligne de commande pour y intégrer toutes les modifications de l'étape 2 ?
Merci. Cordialement.
Gilles
Merci pour ces informations.
Bonne fin de WE.
Cordialement. Gilles
Bonjour,
Merci pour votre réponse. J'avais donc bien compris. Je sais bien que je suis sur un forum d'utilisateurs PostgreSQL mais, si vous le permettez, je vous dirai que je considère cette méthode comme une très mauvaise approche. En cherchant hier soir, j'ai trouvé cet article : http://fossplanet.com/f15/%5Bgeneral%5D … onf-35326/. D'ailleurs même si le fichier était stocké sur le serveur et devait être lu en dur, ce serait tout aussi mauvais car il faudrait ouvrir des droits sur ce répertoire.
Je considère que cela présente un problème de sécurité et également de mise en pratique. Sur chaque station utilisée, il faut générer le fameux fichier... Evidemment, je conçois totalement que cette méthode puisse être considérée comme sûre et pratique, et donne toute satisfaction dans d'autres environnements (ie situations d'accès aux postes notamment) que le mien.
En tout état de cause, je ne comprends pas pourquoi l'équipe de développement n'a pas intégré dans son pg_dump, la possibilité d'utiliser le client/serveur pour questionner la base. En effet, dans la plupart des cas, les bibliothèques nécessaires pour utiliser PGsql devant être installées sur le poste client, la taille de l'exécutable en aurait peu souffert. Je ne considère la solution actuelle "adaptée" que dans un cas : celle où gp_dump est installée sur un poste (serveur) dédié exclusivement à la sauvegarde. Dans ce cas, la présence du fichier est un moindre risque et un moindre soucis d'installation.
Je vous remercie pour votre disponibilité.
Cordialement. Gilles
Bonjour,
je voudrais utiliser pg_dump à partir de ma station locale (192.168.0.36) sur mon serveur (192.168.0.15).
L'objectif final est d'obtenir une sauvegarde d'une base située sur le serveur à partir d'un programme développé en Lazarus sous Windows et sous Linux et exécuté sur la station locale.
Première étape :
PostgreSQL 8.4 est également (pour l'instant) installé sur le 192.168.0.36. Les exe sont dans G:\Wamp\PostgreSQL\bin (Windows 7)
La base, installée sur le serveur (192.168.0.15) , s'intitule basetest, le username est usertest et son password est userpass
chcp 1252
set PSQL="G:\Wamp\PostgreSQL\bin"
%PSQL%\pg_dump --host=192.168.0.15 --username=usertest basetest > c:\test.sql
Cela passe... Mais dans la console, je dois remplir "Mot de passe".
>> Comment règle-t-on ce problème du mot de passe en "interne" à la mySQLdump --password=PASSWD -u USER DATABASE... ?
Méthode préconisée dans les forums : "Sur Microsoft Windows, le fichier est nommé %APPDATA%\postgresql\pgpass.conf (où %APPDATA% fait référence au sous-répertoire Application Data du profile de l'utilisateur"). Ce fichier devra être composé de lignes au format suivant (une ligne par connexion) : nom_hote:port:database:nomutilisateur:motdepasse.
Pour moi, si c'est l'unique réponse, c'est déjà incompréhensible : on parle bien de client/serveur ? Et il faut commencer par aller à la pêche dans un répertoire LOCAL, lire directement des fichiers txt dans lesquels sont écrits EN CLAIR des renseignements contenus par le serveur... la chaine complète d'accès à la base qui plus est ? Et sous Nux, cela serait du même acabit... sans oublier un chmod 0600 ~/.pgpass ?
N'y a-t-il pas une autre méthode propre à PostgreSQL (autre que celle signifiée dans pg_dump --help --> --no-password qui nécessiterait la création d'un utilisateur sans mot de passe qui pourrait accéder à la base) qui ne me semble pas plus sûre que l'autre méthode ?
Il y a évidemment une autre méthode de sauvegarde envisageable par la programmation... bien plus fastidieuse mais cryptable.
Mais enfin si quelqu'un(e) a une autre solution, je suis preneur (cf discussion précédente avec Gleu : "Ou, en effet l'approche de ces lignes de commande est délicate, ou elle ne l'est pas.").
Merci. Cordialement.
Gilles
Je vous remercie. J'ai jusqu'à la fin des vacances scolaires pour prendre une décision... sachant que l'adaptation de nos programmes d'une BDD à l'autre représente(rait) un travail peu important (quelques corrections de requêtes SQL). Donc, j'ai le temps de m'adapter.
Le problème n'est pas non plus "immédiatement" crucial. Mais, même dans un établissement scolaire, on est attentif au problème des licences... Le "mySQL de chez Oracle" a désormais un fork (comme OpenOffice). C'est une alternative dans l'immédiat mais sa perrenité n'est pas acquise... d'où mon regain de curiosité pour Postgresql malgré mes mauvais souvenirs.
Ce que j'essaie de déterminer dans un premier temps, c'est la nature du problème. Ou, en effet l'approche de ces lignes de commande est délicate, ou elle ne l'est pas.
Si c'est le deuxième cas, avec un peu de méthode, une documentation efficace et l'aide de votre forum, je devrais y arriver. Si c'est le premier cas -qui m'avait dissuadé d'utiliser PostgreSQL-, je crois que je n'aurai pas la patience. En effet, on ne peut pas revendiquer "This section attempts to outline to what extent PostgreSQL conforms to the current SQL standard." et en même temps présenter des outils de lignes de commande requérant recettes de cuisine et incantation (c'est ce dont je m'étais persuadé à l'époque).
Donc, je ne vais pas solliciter votre temps inutilement. Je vais ouvrir un nouveau post pour le problème du dump en ligne de commande sur le serveur à partir de ma station de travail (en réseau local). Ceci me permettra de réactualiser mon opinion.
Cordialement. Gilles
Bonjour,
Merci pour votre réponse rapide. Curieux ce message. Il fait pourtant bien état d'une différence entre Windows et les autres OS. Ce que semble infirmer votre réponse.
Je dois reconnaître que je connais mal PostgreSQL après un essai "cuisant" il y a quelques années. J'ai installé PostgreSQL 8.4 sur mon poste de développement et un autre sur un serveur Windows pour faire une évaluation de la modification nécessaire de nos pratiques pour s'adapter éventueller à "The world's most advanced open source database" dixit www.postgresql.org.
Je rencontre actuellement 2 gros problèmes. Un d'ergonomie et un fonctionnel au niveau des lignes de commandes sachant qu'ils ne sont pas rédhibitoires pour nous, parce qu'en utilisant notre langage de programmation (Lazarus), j'ai déjà transféré certaines de nos bases sur le serveur de test aussi bien accessible sur notre réseau local qu'à distance (par internet donc)... et que les tests des programmes (Nux et Win) qui utilisent ces bases sont tout à fait satisfaisants aussi bien sur le réseau local qu'à distance.
Ce qui l'est beaucoup moins, c'est la gestion des bases directement par l'environnement PostgreSQL soit en ligne de commande, soit par la plateforme web.
Exporter nos bases mySQL en fichiers.sql compatibles avec PostgreSQL a été relativement facile. C'est après que cela c'est compliqué. Théoriquement, c'est simple. J'ai voulu transférer une base complète mySQL (à partir d'un fichier.sql rendu compatible PostgreSQL)... et là je suis tombé de haut.
J'ai créé ma base, mes rôles en ligne de commande sur le PostgresSQL de mon poste local... et j'ai dû faire pareil DIRECTEMENT sur mon serveur parce qu'à patir de mon poste de développement, cela n'a pas été possible. J'ai créé ensuite mes tables à partir du fichier.sql à l'aide d'un programme développé pour l'occasion en Lazarus. Cela fonctionne en local, sur le serveur à partir d'un accès sur le réseau et également à partir d'un accès distant ce qui semble indiquer que les divers PostgreSQL sont correctement paramétrés.
Mais en ligne de commande, échec total... même un dump ! Et sous web, même sur mon poste local, je rencontre le message ci-dessus.
Donc, je résume, fonctionnellement à partir de nos programmes, l'accès aux bases installées et leur exploitation sont corrects. Mais, je rencontre à nouveau les mêmes problèmes qu'il y a 3 ans : des fonctions en lignes de commande extrêmement rétives. Est-ce dû à des réglages très particuliers que nécessiteraient ces lignes de commandes ? Des outils Web à l'ergonomie et aux fonctionnalités défaillantes : quand on travaille avec du langage SQL, ne pas importer ou exporter directement des fichiers SQL, c'est curieux... Petite précision nécessaire : toutes nos bases sont en UTF8... Est-ce que le nécessaire chcp1252 en ligne de commande sous Windows peut poser problème ? En ce cas, ce serait une énorme différence avec les autres OS !
Merci de votre aide. Cordialement.
Gilles.
Bonjour,
Comment dois-je interpréter le message d'erreur de phpPgAdmin fonctionnant sous Wamp "La sauvegarde de table complexe et des noms de schémas n'est pas supporté sur Windows" ? La table de test comprend 3 champs (PostgreSQL 8.4.8).
Est-ce que cela sous-entend qu'une version Windows n'a pas les mêmes capacités qu'une version Linux ? Accessoirement, pourquoi existe-t-il un problème d'encodage des caractères accentués dans le message d'erreur ?
Et dans l'autre sens, est-il possible d'importer directement un fichier.sql (CREATE TABLE + INSERT) ? Les formats d'importation autorisés se limitent à Auto (?), CSV, Tabulé, XML dans phpPgAdmin ?
Cordialement. Gilles
Oui, c'est bien ce que je pensais... mais je me demandais s'il n'y avait pas un moyen de contourner cette contrainte en utilisant une astuce SQL (une table temporaire...). Je vais supprimer la déclaration de cette contrainte dans ma table et gérer ce problème d'intégrité référentielle directement dans le langage de programmation utilisé pour mon application.
Merci pour la rapidité de votre réponse.
Cordialement. Gilles
