Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 01/02/2017 16:45:25
- jplaroche
- Membre
suite de la discution pgAmind4 et fork pgAdmin3
lors d'une demande d'ouverture de de sujet , l'Admin m'a suggéré (plutôt dit de regarder avec prudence) le fork pgAdmin3 valide pour pgSQL 9.6.x
a) oui cela existe bien
b) avec bigsql mais pour windows
c) il y a un gti a disposition ...
enfin de compte la demande du Fork n'est pas appuyé par l'équipe de postgresql , mais accepté si il reste dans la licence.
Quand ont regarde l'ensemble des obligations pour l'install , il faut remonter (wxwidgets et gtk )a 2.8 , pytnon ancienne version ... ect...,
on comprends mieux pourquoi ils ont lâché l'affaire , et pour moi le retro pédalage est trop coûteux.
dans un mail de conversation entre l'équipe du fork et postgresql , postgresql dit qu'il feront le nécessaire pour amélioré et plus, et ne soutiendront pas le fork .
alors à quand un ppa pgadmin4 ....
@bientôt de vous lire
ps(je ne vous donne pas l'adresse du git croyez-moi trop de problèmes malgré que le GUI est encore un peu plus avancé a ce jour 2017-02-01)
Bonjour, Arrive de DB2 1978--à ce JOUR
pratique ECPG depuis 2013-- à ce JOUR
Hors ligne
#2 01/02/2017 19:41:50
- rjuju
- Administrateur
Re : suite de la discution pgAmind4 et fork pgAdmin3
Avez-vous également regardé ce fork (https://github.com/dimv36/pgadmin3 ) qui semble relativement actif ?
Julien.
https://rjuju.github.io/
Hors ligne
#3 01/02/2017 22:17:30
- gleu
- Administrateur
Re : suite de la discution pgAmind4 et fork pgAdmin3
Juste un ajout. Il existe une version de pgAdmin III qui supporte la version 9.6. Il s'agit de la version 1.22.2.
Il existe ensuite différents forks (dont celui de bigsql), dont la durée de vie, à mon avis, sera très courte.
Guillaume.
Hors ligne
#4 14/02/2017 20:10:44
- jplaroche
- Membre
Re : suite de la discution pgAmind4 et fork pgAdmin3
bonjour ,
la version 1.22.2
effectivement la version la version 1.22.2 fonctionne
mais elle creer a chaque demande une 9.5 par defaut
j'ai mis a jour la version 9.6.2 postgresql lui ne présente aucun problème
rappel pgsql 9.6.2 pgadmin4 1.2
pour la version pgadmin4
toujours les mêmes problèmes avec pgadmin4
la maintenance ne fonctionne pasbeug style (creation job failed) (sauf si vous ête en admin sudo)
mais ne remonte aucun résultat
pour que cela fonctionne ne pas exécuter avec l'onglet maintenance
solution avec le script passer par l'interface editor sql idem que pour create table si dessus
VACUUM FULL VERBOSE ;(full table)
VACUUM FULL VERBOSE votre_table ;
pgsql 9.6 vacuum
dommage ça rends le pgadmin un peu étriqué
une solution (avec dbeaver logiciel communautaire )
j'ai essayer divers solutions pour le moment rien ne remplace pgadminIII et la version 4 n'est pas terminé . au 15/02/2017
d'autre part je crains la compatibilité ou dut moins je voudrais que ça colle 100% hors les base accès Universelle c'est du 95% exemple charactere(3) devient bpchar(3) et cela me chagrine car je me dit que la représentativité n'est pas exacte .... ou 90% dans certains logiciels exemple lors de la création de tables.
je suis tatillon avec la BD car j'étais architecte depuis 1980 alors comme je suis un papy j'ai des exigences dut à la responsabilité tant en maintenance quand faisabilité ainsi que fiabilité.
j'ai fais une étude de plus d'un an pour choisir une BD autre que DB2 AS400 et mon choix c'est porté sur postgresql qui pour moi représente un gage de respect des normes SQL et de sa fiabilité ainsi que sa portabilité.
Dernière modification par jplaroche (15/02/2017 10:59:54)
Bonjour, Arrive de DB2 1978--à ce JOUR
pratique ECPG depuis 2013-- à ce JOUR
Hors ligne
#5 19/03/2017 08:36:41
- jplaroche
- Membre
Re : suite de la discution pgAmind4 et fork pgAdmin3
postgresql 9.6.2
version 4 1.3
le vacuum fonctionne.
# DATA
pg_dump --format custom -a --encoding utf8 --host 127.1.1 --port 5432 --username postgres CGIFCH > $CGIFCH_DATA
# SCHEMA
pg_dump --format custom --section pre-data --section post-data --encoding utf8 --host 127.1.1 --port 5432 --username postgres CGIFCH > $CGIFCH_SCHEMA
puis
# recharge et creation des tables et leurs definitions
pg_restore --host localhost --port 5432 --username postgres --dbname CGIFCH $CGIFCH_SCHEMA
# recharge les données
pg_restore -a --host localhost --port 5432 --username postgres --dbname CGIFCH $CGIFCH_DATA
la catastrophe plus de schéma ????
j'ai essayé à la main
-- TABLE: "FC0CLI"
-- COPY "FC0CLI" FROM '/home/soleil/AS400/DEF_SQL/FC0CLI.csv' WITH DELIMITER '|' QUOTE '}' csv ENCODING 'WINDOWS-1250';
-- DROP TABLE "FC0CLI" ;
CREATE TABLE public."FC0CLI"
(
"C0CDEP" character(3 ), -- CODE DEPARTEMENT
"C0NCLI" numeric(6,00), -- N° CLIENT
CONSTRAINT "FC0CLI_pkey" PRIMARY KEY ("C0NCLI")
)
WITH (
OIDS=FALSE
);
ALTER TABLE public."FC0CLI"
OWNER TO postgres;
COMMENT ON TABLE public."FC0CLI"
IS 'CLIENT FACTURATION';
COMMENT ON COLUMN "FC0CLI"."C0CDEP" IS 'CODE DEPARTEMENT';
COMMENT ON COLUMN "FC0CLI"."C0NCLI" IS 'N° CLIENT';
strictement identique au pg_restore pas de schéma à l'affichage
pour avoir votre schéma il faut passer par la création de colonne ????
par contre en utilisant la création de colonne l'affichage fonction et vous obtenez un script mais faux exemple
COCDEP character[] length 3 info CODE DEPARTEMENT donne le script "C0CDEP" character(3 )[] ...... le script imprenable en sql si vous le conserver
résultat des améliorations mais aussi des beug supplémentaire !!!! c'était pourtant pas difficile de récupérer les définitions et de les ré-afficher
je lâche l'affaire et reviens en 9.5.6 avec pgadmin III je stop l'évolution je testerait maintenant à la fin de l'année et encore ..... Je n'avais rien mis en prod je voulais être sur de la maintenance qui pour est aussi important que la création. en plus pas de .deb ni ppa alors ....
je crois que je vais me faire un outils médian qui permet de construire des tables.... et d'avoir un référentiel alors je reprendrais le cours de Postgresql . trop de souci pour géré l'architecture d'une base de donnée . @bientôt
Bonjour, Arrive de DB2 1978--à ce JOUR
pratique ECPG depuis 2013-- à ce JOUR
Hors ligne
#6 19/03/2017 08:43:03
- gleu
- Administrateur
Re : suite de la discution pgAmind4 et fork pgAdmin3
Pour commencer, merci de créer une discussion par problème et non pas les entasser dans la même discussion.
Ensuite, je ne comprends pas grand chose à ce que vous dites.
strictement identique au pg_restore pas de schéma à l'affichage
Qu'est-ce que vous entendez par schéma ? Quant à l'affichage, je suppose que vous parlez de ce qu'affiche pgAdmin... avez-vous pensé à rafraichir le navigateur ?
pour avoir votre schéma il faut passer par la création de colonne ????
Une colonne n'a pas de schéma. Une table, une vue, une procédure stockée, oui. Mais pas une colonne. Du coup, je pense qu'on ne parle pas de la même schéma pour les schémas.
Concernant pgAdmin4, personnellement, je pense en effet qu'il faudra attendre bien un an pour qu'il se stabilise.
Guillaume.
Hors ligne
#7 20/03/2017 08:44:48
- jplaroche
- Membre
Re : suite de la discution pgAmind4 et fork pgAdmin3
Pour commencer, merci de créer une discussion par problème et non pas les entasser dans la même discussion.
Ensuite, je ne comprends pas grand chose à ce que vous dites.
strictement identique au pg_restore pas de schéma à l'affichage
Qu'est-ce que vous entendez par schéma ? Quant à l'affichage, je suppose que vous parlez de ce qu'affiche pgAdmin... avez-vous pensé à rafraichir le navigateur ?
pour avoir votre schéma il faut passer par la création de colonne ????
Une colonne n'a pas de schéma. Une table, une vue, une procédure stockée, oui. Mais pas une colonne. Du coup, je pense qu'on ne parle pas de la même schéma pour les schémas.
Concernant pgAdmin4, personnellement, je pense en effet qu'il faudra attendre bien un an pour qu'il se stabilise.
je pensais faire le suivi et je ne dois pas être le seul dans ce cas ..... et je m'attendais a un peu plus d'activité sur le sujet.
breff j'arrive de l'aS400 c'est vrais là il n'y a pas de problème . le schéma est vue comme une procédure stockée pour parler dans votre langage mais le catalogue représente bien plus que çà
quand à la définition type SQL 'puisque le mot schémas ne vous plaît pas ' d'une version à l'autre pour pgadmin4 varie beaucoup , je comprends bien que cela évolue mais quand on marque que c'est la meilleurs au monde ..... il faut faire en sorte au moins de donner l'équivalent au départ et fonctionnel .
pour la définition d'une colonne : lorsqu'on ne retrouve pas la même chose dans une procédure stockée ?????
j'ai plus de 40 ans de service je veux bien être un papy mais je sais me servir d'un PC depuis les année 85 mes premiers logiciels pour AMI association médecine international à titre gratuits....
un schémas: Définition d'une Data Structure (DDS) ou procédure stockée de définition de table. l'ensemble du mots schéma pour une table recouvre ce qui peut permettre de comprendre sa définition ses autorisations ect...
Dans l'exemple suivant le schéma catalogue défini la table des clients facturation est créé en même temps.
exemple raccourci ... pgadminIII car je ne peut pas vous le fournir en pgadmin4 v1.3 venant d'une procédure stockée (sauf si vous passer par la création de colonnes ... ou la représentation de la procédure stockée n'est pas viable ) par contre fonctionnait en v1.2 allez-y comprendre quelques choses effectivement c'est un manière de pas avoir de beug que de supprimer les affichages .....
- Table: public."FC0CLI"
-- DROP TABLE public."FC0CLI";
CREATE TABLE public."FC0CLI"
(
"C0CDEP" character(3), -- CODE DEPARTEMENT
"C0NCLI" numeric(6,0) NOT NULL, -- N° CLIENT
CONSTRAINT "FC0CLI_pkey" PRIMARY KEY ("C0NCLI")
)
WITH (
OIDS=FALSE
);
ALTER TABLE public."FC0CLI"
OWNER TO postgres;
COMMENT ON TABLE public."FC0CLI"
IS 'CLIENT FACTURATION';
COMMENT ON COLUMN public."FC0CLI"."C0CDEP" IS 'CODE DEPARTEMENT';
COMMENT ON COLUMN public."FC0CLI"."C0NCLI" IS 'N° CLIENT';
plus la peine de répondre je laisse tombé . de toute façon il n'y a pas de discussion sur ce sujet , soit les personnes sans foutes ou qu'ils ce sont tourné vers autre chose . ou qu'il n'y a aucun intérêt.
je vais résoudre mon problème autrement, dommage que Postgresql est accepté cela , son image sans trouve ternie. Fournir un outil peu fiable de base .....
quand à l'usure de la version pgadmin4 si vous ne comprenez pas c'est sûrement que vous ne l'utilisez pas sinon vous auriez trouvé mes problèmes tant il sont évident et rende l'utilisation impossible et surtout pas fiable.
merci d'avoir pris le temps de lire.
Dernière modification par jplaroche (20/03/2017 09:27:52)
Bonjour, Arrive de DB2 1978--à ce JOUR
pratique ECPG depuis 2013-- à ce JOUR
Hors ligne
#8 20/03/2017 13:58:02
- gleu
- Administrateur
Re : suite de la discution pgAmind4 et fork pgAdmin3
Ce n'est pas que le mot schéma ne me plaît pas, c'est qu'il faut qu'on parle de la même chose. Il me semble logique que, pour parler de PostgreSQL, on utilise la terminologie PostgreSQL. Et sans vouloir être insultant, pour pouvoir vous répondre, il faut comprendre en premier lieu le problème. Vos phrases ne sont pas des phrases. Ça manque de ponctuation, ça manque de cohérence... je suis désolé, j'aimerais bien vous aider, mais je ne comprends rien à vos messages.
Enfin, concernant pgAdmin4, personnellement, je ne l'utilise pas. Je ne connais aucun client qui l'utilisent actuellement car trop récent et pas assez stable. J'ai utilisé pgAdmin3 pendant un bon moment, principalement parce que je faisais partie de l'équipe de développement. Mais dans ma vie professionnelle, je n'utilise que psql. C'est extrêmement rare que j'utilise pgAdmin, et généralement il s'agit de pgAdmin pour les clients qui n'utilisent que Windows (là où psql est difficilement utilisable).
Guillaume.
Hors ligne
#9 20/03/2017 21:45:27
- jplaroche
- Membre
Re : suite de la discution pgAmind4 et fork pgAdmin3
Ce n'est pas que le mot schéma ne me plaît pas, c'est qu'il faut qu'on parle de la même chose. Il me semble logique que, pour parler de PostgreSQL, on utilise la terminologie PostgreSQL. Et sans vouloir être insultant, pour pouvoir vous répondre, il faut comprendre en premier lieu le problème. Vos phrases ne sont pas des phrases. Ça manque de ponctuation, ça manque de cohérence... je suis désolé, j'aimerais bien vous aider, mais je ne comprends rien à vos messages.
Enfin, concernant pgAdmin4, personnellement, je ne l'utilise pas. Je ne connais aucun client qui l'utilisent actuellement car trop récent et pas assez stable. J'ai utilisé pgAdmin3 pendant un bon moment, principalement parce que je faisais partie de l'équipe de développement. Mais dans ma vie professionnelle, je n'utilise que psql. C'est extrêmement rare que j'utilise pgAdmin, et généralement il s'agit de pgAdmin pour les clients qui n'utilisent que Windows (là où psql est difficilement utilisable).
bonjour,
moi j'utilise pgadmin parce que :
j'ai besoin de comprendre pour faire des migrations de base de donnée DB2 AS400 et PostgreSql .
bien-sur j'utilise la documentation de PostgreSql , pour travailler et pour générer avec les formats mise à disposition du catalogue.
synoptique de traitement :
envoyer sous format csv de puis l'as400 (simple)
envoyer la procédure identique à une création faite par PostgreSql afin d'automatisé cette migration et transferts de données .(simple )
puis je fais une extraction avec ECPG de postgresql sous format XML .
puis je prépare mes librairies (génération automatique de code ECPG ) de tel manière que lorsque les programmes les utilises, le partage (1)OPDP soit actif au sein du process . D’où un gain très important lors du développement et en maintenance .
exemple:
Je reprends les programmes qui font du CGI sur AS400 en RPGILE(langage natif du 400), et les récris puisque j'ai fait les LIBc++ je me retrouve à faire du CGI en mode LG4 le BUT, et la tranquillité d'utiliser les tables d'une façon uniforme. pourquoi le CGI parce-qu’en plus d'être portable , aujourd'hui avec le (2)websocket on peu faire du temps réel.
les résultats sont surprenant tant en rapidité , ainsi que pour la sécurité (voir rollback et accès ainsi que la tenu d'enregistrement avec le websocket)
les méthodes étant validé le service Informatique et le DBA , ils prennent actes et tout rentre dans les process à suivre pour le développement .
voilà pourquoi je m'inquiète:
vouloir une évolution constante afin de bénéficier des améliorations ( sur l'as400 cet une obligation ce qui permet d'avoir aucun métro de retard).
De plus le DBA lui regarde avec la vue pgadmin , et moi je regarde avec les procédures mise à disposition par PostgreSql et pgadmin . Jusqu'à présent il y avait une cohérence. Maintenant en 9.6.2 et pgadmin4 v1.3 ce n'est plus le cas.
je ne cherche pas à avoir raison. je vous fourni la raison des problèmes .
je ne demande pas une solution , mais simplement si quelqu'un est partie sur une autre solution je serais preneur, ou pour partager. (enfin dommage que personne n'est intéressé)
d’où la définition de data structure que je pense devoir développer afin de répondre au DBA, et au service informatique .
@bientôt
ps peut-être suis-je plus clair.
(1)OPDP: partage des process(fonction), des objet(field), des data(donnée), dans un même espace donc les process et Objets ne sont définit qu'une seul fois pour l'ensemble du projet.
(2) WEBSOCKET : solution validé par l'ensemble des acteurs Informatique et les grandes Industries, janvier 2016.
Bonjour, Arrive de DB2 1978--à ce JOUR
pratique ECPG depuis 2013-- à ce JOUR
Hors ligne
Pages : 1