Vous n'êtes pas identifié(e).
Pourquoi n'y avais-je pas pensé!
C'est exactement ce que je souhaitais faire : réaliser l'import en conservant les différentes lignes.
COPY adresses_t(id, adresse) FROM stdin;
1{TAB}boulevard du Brouillard\r\n75001\r\nParis (avec les \\r\\n)
2{TAB}impasse des Grenouilles\n33102\nPétaouchnock (avec le \\n seulement)
\.Je ne m'attendais pas à ce que le codes \r soit présent dans les cellules. Je ne m'attendais pas non plus à l'ajout d'espaces et des "+" en fin de ligne.
En omettant le "retour chariot" et ne conservant que le 'nouvelle ligne' cela me convient tout à fait.
SELECT * FROM adresses;
id | adresse
----+----------------------------------
1 | boulevard du Brouillard\r +
| 75001\r +
| Paris (avec les \r\n)
2 | impasse des Grenouilles +
| 33102 +
| Pétaouchnock (avec le \n seulement)
(2 lignes)Merci beaucoup aussi pour le lien vers l'usage de COPY. Sa relecture n'a pas été superflue.
Bonjour le forum,
Dans la base de données MS Access :
J'ai une colonne dont certaines cellules contiennent plusieurs lignes. Ces lignes sont distinctes entre elles car elles se terminent par des CR/LF.
Le type de données de cette colonne est "Mémo". Il contient des adresses.
Voici un exemple du contenu de deux tuples dont la colonne [adresse] me pose problème :
[id][adresse]
1 boulevard du Brouillard{CR LF}
75001{CR LF}
Paris
2 impasse des Grenouilles{CR LF}
33102{CR LF}
PétaouchnockDans Postgresql :
Voici la table dans laquelle je veux importer les données :
CREATE TABLE adresses (
id SERIAL UNIQUE NOT NULL,
adresse CHARACTER VARYING(30)
);A l'import, cela se passe mal.
Motif : les CR/LF perturbent la structure du fichier d'import : 1 tuple = 1 ligne terminée par CRLF. Cette structure n'est plus respectée.
Voici le fichier d'import :
COPY adresses(id, adresse) FROM stdin;{CR LF}
1{TAB}boulevard du Brouillard{CR LF}
75001{CR LF}
Paris{CR LF}
2{TAB}impasse des Grenouilles{CR LF}
33102{CR LF}
Pétaouchnock{CR LF}
\.{CR LF}Pour préserver la lisibilité de mon message, j'ai changé les codes hexa non imprimables par des CR, LF et TAB
Dans Postgresql, je veux conserver ces CR/LF pour réutiliser ce formatage dans d'autres usages.
Si je remplace ces CR LF perturbants par des TAB et que je modifie la table en conséquence alors je peux procéder à l'import mais je perd le formatage. Ce que je ne veux pas.
Il s'agit de plusieurs milliers de tuples à migrer.
Est-ce possible? Comment?
Merci beaucoup par avance pour toutes suggestions.
C'est exactement ce que je cherchais. Lors de mes recherches j'avais vu l'existence des window function mais je les avait écartées car ne voyais pas le rapport avec ce que je cherchais.
Merci beaucoup.
Bonjour la liste,
Je rencontre une difficulté pour formuler correctement ma recherche sur le web.
Il s'agit de cumuler des coupes de bois annuelles qui alimentent un bûcher.
Ce que j'ai:
DROP TABLE IF EXISTS matable CASCADE;
CREATE TABLE matable
(
annee INTEGER UNIQUE NOT NULL,
m3 NUMERIC(3,1)
)
;
COPY matable (annee, m3) FROM stdin;
2015 3.6
2016 0.0
2017 2.3
2018 4.5
2019 0.8
2020 9.4
2021 13.4
2022 0.5
\.Ce que je souhaite obtenir mais que je ne sais pas formuler:
annee | cumul_m3
-----+------
2015 | 3.6
2016 | 3.6
2017 | 5.9
2018 | 10.4
2019 | 11.2
2020 | 20.6
2021 | 34.0
2022 | 34.5Je vous remercie par avance pour m'indiquer quelle instruction je dois utiliser pour afficher ces cumuls annuels.
bonjour,
Est-ce vraiment utile de stocker un élément calculé ?
Bonjour,
Non, ce n'est pas vraiment utile.
C'est un script Bash déclenché par une tâche Cron qui va chercher cet élément.
Il est mis dans une page html qui est envoyée par email.
SELECT "date", releve,
releve - lag(releve, 1) OVER (PARTITION BY 1 ORDER BY "date") as parcouruVoilà une structure de requête que je n'avais jamais vue!
et du coup plus besoin de la colonne parcouru dans la table.
C'est exact. Je confirme.
J'ai mis la requête dans une vue. Le script Bash va pouvoir trouver l'élément calculé qu'il a besoin.
Du coup, à part un copié/collé de la requête, je n'ai rien eu à faire.
En postant ici, je n'en demandais pas tant!
Merci beaucoup!
Je reste émerveillé devant cette requête qui fourni un élément calculé.
Je vais l'étudier de près.
Je vais donc me mettre aux fonctions.
Merci de m'avoir mis sur la bonne voie car je n'en étais pas sûr.
Merci pour ce retour.
1)
Pour calculer la valeur de la colonne (parcouru) je pense qu'il faut identifier la date la plus récente puis celle immédiatement avant. Je devrais m'en sortir plus ou moins élégamment.
2)
Par contre il n'y a pas à insérer de ligne puisqu'il s'agit d'un UPDATE du champ (parcouru).
C'est là que je butte : comment updater automatiquement ce champ si une valeur de la colonne (releve) est modifiée.
Bonjour le forum,
J'imagine que cela doit être aussi simple avec Postgresql qu'avec un tableur mais je ne sais pas par quel bout commencer car je n'ai jamais fait de calculs à partir de champs disposés dans deux tuples.
Mon but c'est de faire un UPDATE sur la colonne (parcouru).
La méthode de calcul est très simple puisqu'il ne s'agit que de faire une différence de relevés entre deux dates consécutives.
CREATE TABLE comptage(
date date UNIQUE,
releve numeric(9,0),
parcouru numeric(9,0)
);
COPY comptage(date,releve) FROM stdin;
2015-12-22 7
2001-01-01 2
2016-09-22 10
\.Dans la table, les enregistrements n'arrivent pas systématiquement dans l'ordre chronologique de la colonne (date).
Si une valeur (releve) est modifiée ultérieurement, la colonne (parcouru) devra être automatiquement "updatée".
Au final, voici ce que je veux obtenir :
COPY comptage(date,releve,parcouru) FROM stdin;
2015-12-22 7 5
2001-01-01 2 0
2016-09-22 10 3
\.Je butte sur la mise à jour permanente de la colonne (parcouru) entre deux dates de relevés consécutifs.
Est-ce que la solution c'est de faire appel à une fonction? Je ne les ai encore jamais abordées.
Pour surveiller ma table, j'ai trouvé quelque chose qui me semble être un point de départ ici:
http://forums.postgresql.fr/viewtopic.php?id=3866
Merci par avance de m'indiquer comment on traite d'habitude ce genre de problème.
En effet, maintenant le format est de longueur fixe :
CREATE VIEW mavue AS
SELECT to_char (chrono::time,'HH24:MI:SS.MS') AS chrono
FROM matable; chrono
--------------
00:00:42.000
00:00:42.150
Ce ne me sera pas trop difficile que de supprimer ce zéro de queue en trop pour avoir des centièmes de secondes.
Merci beaucoup pour la réponse.
Bonjour le forum,
Je souhaite afficher un chronométrage sous ce format :
00:00:42.15
CREATE TABLE matable (chrono time without time zone);
COPY matable (chrono) FROM STDIN;
00:00:42.00
00:00:42.15
\.
CREATE VIEW mavue AS SELECT * FROM matable;Le résultat de la requête fait que les zéros de queue non significatifs
sont supprimés:
chrono
00:00:42
00:00:42.15
Je souhaite conserver ces zéros non significatifs car derrière, il y a
un script bash qui récupère la vue. Celui-ci travaille sur la longueur
de la chaîne et je ne souhaite pas le modifier.
En précisant le 100è de seconde dans la table,
CREATE TABLE matable (chrono time (2) without time zone);comme le résultat est le même j'ai pensé chercher dans les fonctions de
formatage :
http://docs.postgresql.fr/8.2/functions … ting-table
On y parle de "to_char(timestamp, text)" alors que dans ma table ce
serait peut-être un "time --> texte"
Est-ce que je fais fausse route où y a-t-il une autre façon de ne pas
perdre ces zéros de queue dans la table?
Merci par avance.
Merci beaucoup pour votre réponse.
Comme je ne souhaite pas utiliser les backports, cela implique que je doit aligner toutes mes Debian qui communiquent avec Postgres.
Si le dump est exécuté localement par l'utilisateur sur sa base alors il n'y a aucun message d'erreur.
$ pg_dump > dump.sql
Mot de passe :
$Bonjour le forum.
Mon niveau est juste "basique" avec Postgres et tout est dans le titre.
Comme je viens de créer une nouvelle base de données, avant de la remplir, je commence par mettre en place sa sauvegarde ;-)
Je découvre immédiatement ceci :
$ pg_dump -i -D -h 192.168.1.4 -U archimede archimede > dump.sql
Mot de passe :
pg_dump: version du serveur : 8.4.5 ; pg_dump version : 8.3.13
pg_dump: traitement malgré la différence des versions
pg_dump: la commande SQL a échoué
pg_dump: Message d'erreur du serveur : ERREUR: la colonne « reltriggers » n'existe pas
LINE 1: ...oles WHERE oid = relowner) as rolname, relchecks, reltrigger...
^
pg_dump: La commande était : SELECT c.tableoid, c.oid, relname, relacl, relkind, relnamespace, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = relowner) as rolname, relchecks, reltriggers, relhasindex, relhasrules, relhasoids, d.refobjid as owning_tab, d.refobjsubid as owning_col, (SELECT spcname FROM pg_tablespace t WHERE t.oid = c.reltablespace) AS reltablespace, array_to_string(c.reloptions, ', ') as reloptions from pg_class c left join pg_depend d on (c.relkind = 'S' and d.classid = c.tableoid and d.objid = c.oid and d.objsubid = 0 and d.refclassid = c.tableoid and d.deptype = 'a') where relkind in ('r', 'S', 'v', 'c') order by c.oidLe client est en 8.3 sur une Lenny. Il parle avec :
- un serveur en 8.3 sur une Lenny
- un serveur en 8.4 sur une Squeeze. D'où le "-i" du pg_dump ci-dessus.
Le serveur 8.4, n'est pas sur le même brin de réseau que le client.
Le client peut s'y connecter sans problème.
En cherchant profondément dans ce fil :
http://listes.postgresql.fr/pipermail/t … 00490.html
je crois comprendre qu'il s'agit d'un problème de compatibilité entre les versions avec Slonik.
...
-<li>Change default $LOGDIR, so that distros won't need to patch it.
+ <li> pg_class.reltriggers n'existe plus dans 8.4 et donc ne doit plus être touché
...Si Slonik a été installé, cela a dû être fait automatiquement avec les autres paquets lors de l'aptitude instal...
Il me semble comprendre que les "ubuntéros" avaient réglé un bug :
http://www.mail-archive.com/universe-bu … 61330.html
Est-ce que ça concerne aussi mon cas sous Debian?
J'ai trouvé une autre situation similaire ici:
http://forums.postgresql.fr/viewtopic.php?id=742
Par contre, contrairement à ce dernier cas, moi, je n'ai pas touché aux tables systèmes. Vu mon niveau, je ne m'y aventure pas.
Comme je viens juste d'installer Postgres sur cette nouvelle machine je n'ai fait que de créer/droper des utilisateurs et des bases sous Postgres, des bases, des tables et des vues sous des utilisateurs différents.
Voici la base qui refuse de se laisser dumper :
$ psql -h 192.168.1.4 -U archimede archimede
Mot de passe :
Bienvenue dans psql 8.3.13 (serveur 8.4.5), l'interface interactive de PostgreSQL.
Saisissez:
\copyright pour les termes de distribution
\h pour l'aide-mémoire des commandes SQL
\? pour l'aide-mémoire des commandes psql
\g ou point-virgule en fin d'instruction pour exécuter la requête
\q pour quitter
ATTENTION : vous êtes connecté sur un serveur dont la version majeure est
8.4 alors que votre client psql est en version majeure 8.3. Certaines
commandes avec antislashs, comme \d, peuvent ne pas fonctionner
correctement.
Connexion SSL (chiffrement : DHE-RSA-AES256-SHA, bits : 256)
archimede=> \d
Liste des relations
Schéma | Nom | Type | Propriétaire
--------+-------------------+----------+--------------
public | table1 | table | archimede
public | table1_champ1_seq | séquence | archimede
public | view1 | vue | archimede
public | view2 | vue | archimede
(4 lignes)
archimede=> SELECT * FROM table1;
champ1 | champ2
--------+---------
1 | Ligne1
2 | Ligne2
3 | Ligne3
4 | Ligne4
5 | Ligne5
6 | Ligne6
7 | Ligne7
8 | Ligne8
9 | Ligne9
10 | Ligne10
(10 lignes)
archimede=> \d table1
ERREUR: la colonne « reltriggers » n'existe pas
LINE 1: SELECT relhasindex, relkind, relchecks, reltriggers, relhasr...J'avais créé la table ainsi :
CREATE TABLE table1 (champ1 serial, champ2 varchar(30));Je pourrais mettre ça sur le dos du "\d" qui pourrait ne pas fonctionner correctement mais cela ne tient pas pour pg_dump.
Bref, je fais du ping pong entre un message relatif à reltriggers et celui d'un serveur qui n'accepte que difficilement une compatibilité descendante avec un client.
Est-ce que quelqu'un aurait une idée dans quelles directions devrais-je plutot orienter mes recherches?
Merci par avance.
Je vais continuer à chercher. Peut-être vais-trouver un objet identifiant ou une méthode pour gérer de simples numéros que moi je baptise : identifiants et pour lesquels l'objet séquence de Postgres ne me sert qu'à me faciliter la création au sein d'une progression arithmétique.
Merci beaucoup à vous deux. Je garde vos idées.
Pourquoi avez-vous besoin d'interdire la réutilisation d'un identifiant issue d'une séquence ? les séquences ne sont pas faites pour ça en fait.
Je veux interdire la réutilisation d'un identifiant qu'il soit issu d'une séquence ou de n'importe quelle autre méthode.
La séquence ne m'est utile que pour me simplifier la création d'identifiants structurés.
Exemple d'utilisation :
- Un badge numéroté est délivré à l'entrée d'un parking. Il est détruit à la sortie. Son identifiant ne doit plus jamais être créé sinon on faussera le traçage de ce badge.
Peut-être que ma question est mal formulée.
Il y a l'idée de mettre l'identiant dans une autre table. On peut aussi ajouter une colonne qui indique l'état détruit ou pas. Mais je ne sais pas comment supprimer le risque de l'insert d'identifiants hors séquence.
Bonjour le forum,
Une séquence avec incréments me facilite la création d'identifiants incrémentés.
CREATE SEQUENCE masequence START 10 INCREMENT BY 10;
CREATE TABLE matable (
noid int4 DEFAULT nextval('masequence') UNIQUE,
colonne char(4)
);Mais je ne sais pas assurer une protection contre ce genre d'insertion hors incréments;
INSERT INTO matable (noid, colonne) VALUES (3,3);Il est aussi possible de réutiliser un identifiant identique à celui d'un autre ayant été précédemment détruit.
SELECT noid, colonne FROM matable WHERE noid=3;
noid | colonne
------+---------
3 | 3
DELETE FROM matable WHERE noid=3;
INSERT INTO matable (noid, colonne) VALUES (3,0);Comment interdire ces deux possibiilités :
- je veux interdire l'utilisation d'un identifiant qui n'est pas dans la progression de la séquence
- je veux interdire de recréer un identifiant ayant déjà été détruit
Dans mon apprentissage de Postgres je n'ai pas encore abordé les fonctions ni d'autres outils plus élaborés.
Est-ce dans cette direction que je dois chercher?
Merci par avance pour vos conseils.
Merci pour tous ces points.
Je vais installer pgadmin pour car actuellement je n'utilise que phppgadmin.
Bonjour le forum,
Je cherche à m'organiser pour les sauvegardes des données et pour les structures des bases.
Vu ce que j'ai déjà lu, je comprends que je gère de très petites bases de données.
Je sais sauvegarder les tables, les bases, les données avec pg_dump mais c'est sur la façon de les sauvegarder que je souhaiterai avoir l'avis d'utilisateurs expérimentés.
Les bases sont sur un seul serveur dans un sous-réseau 192.168
Deux utilisateurs peuvent les utiliser en lecture/écriture
Ces deux utilisateurs ont des bases en commun par contre, certaines de leur bases leur sont privées.
Il n'y a pas de gros objets binaires.
Je saurai définir la fréquence des sauvegardes plus tard.
Les sauvegardes vont être mises temporairement sur le même serveur puis elles seront dupliquées (scp) - ou déplacées (je ne sais pas encore) - sur une autre machine.
Je n'ai pas encore l'expérience de précautions des sauvegardes au cours de transactions/rollback.
1)
Pour les sauvegardes ce que j'aimerai savoir c'est si il est préférable :
- que ce soit chaque user unix qui sauvegarde ses propres bases par une crontab. Quid des bases communes?
- ou que je créé un utilisateur unix qui serait uniquement chargé de toutes les sauvegardes mises dans une crontab en préservant les droits de chacun dans le(s) script(s)?
2)
Vu mon expérience de novice, je ne sais pas s'il est préférable de sauvegarder les données d'une part et les structures d'une autre part ou au contraire de tout mettre dans le même dump.
J'ai compris que sauvegarder l'ensemble d'une base avec plusieurs tables/view/sequences/etc... est moins pratique pour restorer ponctuellement.
3)
J'ai aussi vu la possibilité de sauvegarder directement les fichiers des bases mais, pour des très petits volumes, je ne vois pas l'avantage par rapport à pg_dump.
Merci d'avance pour toutes vos suggestions sur les sauvegardes vues sous l'angle de la sécurité.
Oui, c'est plus clair maintenant.
Je n'avais pas compris qu'une séquence n'était prise en compte que sur un INSERT sans valeur pour la colonne t_00_noid (ou avec la valeur DEFAULT).
Je pensais aussi que la clef primaire que j'avais mise dessus permettait de préserver les valeurs détruites de toute réutilisation future :
ALTER TABLE ONLY t_00_dic_medical
ADD CONSTRAINT t_00_dic_medical_pkey PRIMARY KEY (t_00_noid);
Il faut donc que je revoie la contrainte sur la colonne.
Encore merci pour le coup de pouce.
Merci pour votre intérêt.
Voici ce que j'ai fait avec le dump qui génère le message d'erreur :
bd_archimede=> SELECT * FROM t_00_dic_medical;
t_00_noid | t_00_tri | t_00_jp | t_00_class | t_00_fr | t_00_fr_gramm | t_00_uk | t_00_uk_gramm | t_00_explication
-----------+----------+--------------+------------+----------------------+---------------+---------+---------------+--------------------------------------------------------------------
1 | 2 | いぼ（疣） | | verrue | nf | | |
2 | 11 | 傷を焼灼する | | cautériser une plaie | | | | en brûler superficiellement les tissus afin d'éviter son infection
7 | 0 | | | français | | | |
(3 lignes)
bd_archimede=> TRUNCATE t_00_dic_medical ;
TRUNCATE TABLE
bd_archimede=>En ligne de commande :
$ psql -h 192.168.3.105 -U archimede -W bd_archimede < dump_t_00_dic_medical.txt
Mot de passe pour l'utilisateur archimede :
SET
SET
SET
SET
SET
SET
SET
SET
ERREUR: la relation « t_00_dic_medical » existe déjà
ALTER TABLE
COMMENT
COMMENT
COMMENT
COMMENT
COMMENT
COMMENT
COMMENT
COMMENT
COMMENT
ERREUR: la relation « t_00_dic_medical_t_00_noid_seq » existe déjà
ALTER TABLE
ALTER SEQUENCE
setval
--------
6
(1 ligne)
ALTER TABLE
INSERT 0 1
INSERT 0 1
ERREUR: les clés primaires multiples ne sont pas autorisées pour la table « t_00_dic_medical »
ATTENTION: aucun droit n'a pu être révoqué pour « public »
REVOKE
ATTENTION: aucun droit n'a pu être révoqué pour « public »
REVOKE
ATTENTION: aucun droit n'a été accordé pour « public »
GRANT
ATTENTION: aucun droit n'a été accordé pour « public »
GRANT
$Le dump :
--
-- PostgreSQL database dump
--
SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET escape_string_warning = off;
SET search_path = public, pg_catalog;
SET default_tablespace = '';
SET default_with_oids = false;
--
-- Name: t_00_dic_medical; Type: TABLE; Schema: public; Owner: archimede; Tablespace:
--
CREATE TABLE t_00_dic_medical (
t_00_noid bigint NOT NULL,
t_00_tri numeric(6,0) DEFAULT 0,
t_00_jp character varying(100),
t_00_class character varying(10),
t_00_fr character varying(100),
t_00_fr_gramm character varying(10),
t_00_uk character varying(100),
t_00_uk_gramm character varying(10),
t_00_explication text
);
ALTER TABLE public.t_00_dic_medical OWNER TO archimede;
--
-- Name: COLUMN t_00_dic_medical.t_00_noid; Type: COMMENT; Schema: public; Owner: archimede
--
COMMENT ON COLUMN t_00_dic_medical.t_00_noid IS 'Numérotation auto-incrémentée. Maximum = ???? Avec clef primaire';
--
-- Name: COLUMN t_00_dic_medical.t_00_tri; Type: COMMENT; Schema: public; Owner: archimede
--
COMMENT ON COLUMN t_00_dic_medical.t_00_tri IS 'Numéro de tri. Maximum = 1.000.000 de lignes dans ce dictionnaire';
--
-- Name: COLUMN t_00_dic_medical.t_00_jp; Type: COMMENT; Schema: public; Owner: archimede
--
COMMENT ON COLUMN t_00_dic_medical.t_00_jp IS 'Japonais. Limite 100 caractères. A voir les doubles octets';
--
-- Name: COLUMN t_00_dic_medical.t_00_class; Type: COMMENT; Schema: public; Owner: archimede
--
COMMENT ON COLUMN t_00_dic_medical.t_00_class IS 'Japonais pour classement. Limite 10 caractères. A voir les doubles octets';
--
-- Name: COLUMN t_00_dic_medical.t_00_fr; Type: COMMENT; Schema: public; Owner: archimede
--
COMMENT ON COLUMN t_00_dic_medical.t_00_fr IS 'Français. Limite 100 caractères.';
--
-- Name: COLUMN t_00_dic_medical.t_00_fr_gramm; Type: COMMENT; Schema: public; Owner: archimede
--
COMMENT ON COLUMN t_00_dic_medical.t_00_fr_gramm IS 'Français. Grammaire. Limite 10 caractères.';
--
-- Name: COLUMN t_00_dic_medical.t_00_uk; Type: COMMENT; Schema: public; Owner: archimede
--
COMMENT ON COLUMN t_00_dic_medical.t_00_uk IS 'Anglais. Limite 100 caractères.';
--
-- Name: COLUMN t_00_dic_medical.t_00_uk_gramm; Type: COMMENT; Schema: public; Owner: archimede
--
COMMENT ON COLUMN t_00_dic_medical.t_00_uk_gramm IS 'Anglais. Grammaire. Limite 10 caractères.';
--
-- Name: COLUMN t_00_dic_medical.t_00_explication; Type: COMMENT; Schema: public; Owner: archimede
--
COMMENT ON COLUMN t_00_dic_medical.t_00_explication IS 'Explication. Type de champs texte';
--
-- Name: t_00_dic_medical_t_00_noid_seq; Type: SEQUENCE; Schema: public; Owner: archimede
--
CREATE SEQUENCE t_00_dic_medical_t_00_noid_seq
INCREMENT BY 1
NO MAXVALUE
NO MINVALUE
CACHE 1;
ALTER TABLE public.t_00_dic_medical_t_00_noid_seq OWNER TO archimede;
--
-- Name: t_00_dic_medical_t_00_noid_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: archimede
--
ALTER SEQUENCE t_00_dic_medical_t_00_noid_seq OWNED BY t_00_dic_medical.t_00_noid;
--
-- Name: t_00_dic_medical_t_00_noid_seq; Type: SEQUENCE SET; Schema: public; Owner: archimede
--
SELECT pg_catalog.setval('t_00_dic_medical_t_00_noid_seq', 6, true);
--
-- Name: t_00_noid; Type: DEFAULT; Schema: public; Owner: archimede
--
ALTER TABLE t_00_dic_medical ALTER COLUMN t_00_noid SET DEFAULT nextval('t_00_dic_medical_t_00_noid_seq'::regclass);
--
-- Data for Name: t_00_dic_medical; Type: TABLE DATA; Schema: public; Owner: archimede
--
INSERT INTO t_00_dic_medical (t_00_noid, t_00_tri, t_00_jp, t_00_class, t_00_fr, t_00_fr_gramm, t_00_uk, t_00_uk_gramm, t_00_explication) VALUES (1, 2, 'いぼ（疣）', '', 'verrue', 'nf', '', '', NULL);
INSERT INTO t_00_dic_medical (t_00_noid, t_00_tri, t_00_jp, t_00_class, t_00_fr, t_00_fr_gramm, t_00_uk, t_00_uk_gramm, t_00_explication) VALUES (2, 11, '傷を焼灼する', '', 'cautériser une plaie', '', NULL, '', 'en brûler superficiellement les tissus afin d''éviter son infection');
--
-- Name: t_00_dic_medical_pkey; Type: CONSTRAINT; Schema: public; Owner: archimede; Tablespace:
--
ALTER TABLE ONLY t_00_dic_medical
ADD CONSTRAINT t_00_dic_medical_pkey PRIMARY KEY (t_00_noid);
--
-- Name: public; Type: ACL; Schema: -; Owner: postgres
--
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
--Et le nouveau remplissage de la table :
bd_archimede=> SELECT * FROM t_00_dic_medical;
t_00_noid | t_00_tri | t_00_jp | t_00_class | t_00_fr | t_00_fr_gramm | t_00_uk | t_00_uk_gramm | t_00_explication
-----------+----------+--------------+------------+----------------------+---------------+---------+---------------+--------------------------------------------------------------------
1 | 2 | いぼ（疣） | | verrue | nf | | |
2 | 11 | 傷を焼灼する | | cautériser une plaie | | | | en brûler superficiellement les tissus afin d'éviter son infection
(2 lignes)
bd_archimede=>Je n'ai passé aucune autre commande, ni côté serveur, ni sur ma machine. Vous avez ici dans l'ordre la totalité de ce que je vois et de ce que j'ai exécuté.
je voudrais transférer des tables précise
Cela devrait aller avec :
$ pg_dump -D -h ipdistante -U user -W labonnebase -t labonnetable > fichierdesauvegarde
Bonjour le forum.
Suite à un TRUNCATE TABLE qui ne détruit pas le compteur je m'attendais à ce que la progression de la séquence continue en tenant compte de la valeur "last_value" du catalogue.
Lors du repeuplement de cette table devenue vide j'ai constaté que la valeur "last_value" était bien prise en compte mais qu'il était quand même possible de réutiliser des valeurs détruites.
Est-ce normal qu'un INSERT INTO des valeurs de séquences ayant été déjà utilisées soient acceptées quand même avec le message d'erreur "clés primaires multiples ne sont pas autorisées"?
Voici un extrait de la table. Pour la lisibilité, j'ai supprimé les ALTER TABLE... OWNER TO.
CREATE TABLE t_00_dic_medical (
t_00_noid bigint NOT NULL,
t_00_tri numeric(6,0) DEFAULT 0,
t_00_jp character varying(100),
[...]La totalité de la séquence avec une valeur 6 pour "last_value" :
CREATE SEQUENCE t_00_dic_medical_t_00_noid_seq
INCREMENT BY 1
NO MAXVALUE
NO MINVALUE
CACHE 1;
ALTER SEQUENCE t_00_dic_medical_t_00_noid_seq OWNED BY t_00_dic_medical.t_00_noid;
SELECT pg_catalog.setval('t_00_dic_medical_t_00_noid_seq', 6, true);
ALTER TABLE t_00_dic_medical ALTER COLUMN t_00_noid SET DEFAULT nextval('t_00_dic_medical_t_00_noid_seq'::regclass);Je peuple un peu la table pour tester. Le compteur monte à 6. Je la "truncate" puis je la repeuple à nouveau avec ce dump :
INSERT INTO t_00_dic_medical (t_00_noid, t_00_tri, t_00_jp, [...]) VALUES (1, 2, 'いぼ（疣）', [...]); (notez la valeur 1 entrée en première colonne)
INSERT INTO t_00_dic_medical (t_00_noid, t_00_tri, t_00_jp, [...]) VALUES (2, 11, '傷を焼灼する',[...]); (notez la valeur 2 entrée en première colonne)
ALTER TABLE ONLY t_00_dic_medical
ADD CONSTRAINT t_00_dic_medical_pkey PRIMARY KEY (t_00_noid);L'erreur :
$psql labonnebase < dump.txt
[...]
ERREUR: la relation « t_00_dic_medical » existe déjà (Ce message me semble normal car la description de la table est aussi dans le dump)
ALTER TABLE
ERREUR: la relation « t_00_dic_medical_t_00_noid_seq » existe déjà (Ce message me semble normal puisque je n'ai fait que "truncaté" la table et non "droppée")
ALTER TABLE
ALTER SEQUENCE
setval
--------
6
(1 ligne)
ALTER TABLE
INSERT 0 1
INSERT 0 1
ERREUR: les clés primaires multiples ne sont pas autorisées pour la table « t_00_dic_medical »Le résultat :
t_00_noid | t_00_tri | t_00_jp |
-----------+----------+--------------+
1 | 2 | いぼ（疣） |
2 | 11 | 傷を焼灼する |
7 | 0 | |Pour la première colonne, je m'attendais à ce qu'on m'interdise le INSERT INTO 1, 2 et que la séquence reprenne à partir de 7. Je m'attendais donc à cette seule séquence autorisée : 7, 8, 9, et non 1, 2, 7 que j'ai forcé.
La valeur de la séquence dans le catalogue :
select * from t_00_dic_medical_t_00_noid_seq ;
sequence_name | last_value | increment_by | max_value | min_value | cache_value | log_cnt | is_cycled | is_called
--------------------------------+------------+--------------+---------------------+-----------+-------------+---------+-----------+-----------
t_00_dic_medical_t_00_noid_seq | 7 | 1 | 9223372036854775807 | 1 | 1 | 32 | f | tOù est-ce que j'ai fait une erreur?
Qu'est-ce que je n'ai pas compris?
Merci beaucoup d'avance pour le temps que vous accorderez à mes interrogations.
Alain V. a écrit :create database role legroupe role leuser1, leuser2;
Je ne sais pas du tout ce que vous entendez par là.
Effectivement je suis en train de mélanger la notion de groupe avec celle d'une database!
Merci pour le lien. Je vais m'y accrocher.
je dois insérer des informations avec des accents, ce qui n'est pas supporté par ce type d'encodage..
Bonjour,
Moi je peux utiliser tous les accents avec UTF-8.
Je peux aussi utiliser indistinctement les caractères des langues asiatiques.
D'ailleurs, je n'utilise plus que UTF-8, car qui peut le plus, peut le moins.