Vous n'êtes pas identifié(e).
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
Dernière modification par Selzig (20/08/2011 15:25:09)
Hors ligne
Est-ce que cela sous-entend qu'une version Windows n'a pas les mêmes capacités qu'une version Linux ?
Au niveau de PostgreSQL, si. Vous avez exactement les mêmes fonctionnalités (sauf sepgsql en version 9.2 qui est lié à SELinux, qui, comme son nom l'indique, n'est pas disponible sous Windows).
Et dans l'autre sens, est-il possible d'importer directement un fichier.sql (CREATE TABLE + INSERT) ?
Oui, mais il faut passer par l'éditeur de requêtes avec phpPgAdmin (si je me souviens bien).
Guillaume.
Hors ligne
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.
Dernière modification par Selzig (20/08/2011 17:02:43)
Hors ligne
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.
D'après le code de phpPgAdmin, le problème vient plutôt de PHP :
// Due to annoying PHP bugs, shell arguments cannot be escaped
// (command simply fails), so we cannot allow complex objects
// to be dumped.Désolé, mais je n'en sais pas plus sur phpPgAdmin et sur cette restriction. Par contre, il est certain qu'au niveau PostgreSQL, il n'y a actuellement aucune différence en terme de fonctionnalités entre la version Unix et la version Windows.
J'ai créé ma base, mes rôles en ligne de commande sur le PostgresSQLde 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.
Pourquoi ? quelle erreur avez-vous eu ?
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...
Désolé mais c'est suffisamment peu détaillé pour pouvoir vous répondre efficacement. Le mieux est certainement de prendre les problèmes les uns après les autres et de les résoudre ainsi. Créer un thread par problème, indiquer ce que vous faites, l'erreur que vous renvoie PostgreSQL ou le comportement qui vous semble étonnant, et on va essayer de vous aider à régler tout ça 
Guillaume.
Hors ligne
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
Dernière modification par Selzig (20/08/2011 19:31:24)
Hors ligne