Vous n'êtes pas identifié(e).
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.
Bonjour le forum,
Je ne sais pas trop comment formuler mes recherches dans la documentation.
Ce que je veux faire :
- une database de plusieurs tables accessibles à au moins trois users.
- l'un deux ne pourrait que lire (select?) les tables et les vues
- l'autre pourrait altérer (insérer/droper/updater/truncater?) toutes les colonnes, les tuples et bien sûr les tables.
- un troisième ne pourrait qu'insérer et updater quelques colonnes seulement sans possibilité de détruire des données (ajouts + modifs autorisés mais pas de suppressions).
Ce que j'ai fait :
Sous l'utilisateur postgres j'ai commencé par créer un groupe en croyant que ce groupe ne devrait pas avoir de login (aucune entrée dans /etc/password) et en commençant pas deux users :
create database role legroupe role leuser1, leuser2;
Ensuite je patauge allègrement pour attribuer une database à ce groupe sous un autre proprio que postgres tout en grantant des droits différents à chacun des users sur les tables.
J'ai compris que les privilèges accordés aux users sont distincts que ceux du groupe auquel ils appartiennent.
J'ai tenté de tester dans tous les sens (jusqu'à le vider) le pg_hba.conf avec la désagréable sensation que ce ne doit pas être la bonne voie car les accès ne semblent pas être affectés.
Sinon, hormis cette tentative d'avoir un groupe, le pg_hba.conf semble bien correspondre à ce que j'en attends.
Dans cette doc http://docs.postgresqlfr.org/8.2/sql-grant.html je n'ai compris que la possiblité de granter un user sur une table et non plusieurs users sur plusieurs tables au sein d'une seule database.
Je suis désolé si ma description est tordue, mal ou incomplètement formulée.
Est-ce que quelqu'un aurait un lien vers un tuto qui parle de groupes / d'utilisateurs avec des exemples montrant des droits différents sur les tables?
Merci beaucoup par avance de me mettre sur des voies de recherche ou de m'expliquer ce que je n'ai pas compris dans la doc.
Merci beaucoup. Cela me permet d'orienter mes recherches différemment.
D'après ce que j'ai compris pgloader prend en entrée un fichier plat.
J'ai effectivement ce fichier plat mais je souhaite m'en débarasser.
Ce que je cherche à faire c'est que les recettes de Procmail aillent déverser directement dans une table Postgres pour ne plus passer par ce fichier plat.
Il y a un flux constant qui l'alimente. Actuellement je suis obligé d'arrêter le flux manuellement, vider ce fichier et remettre le flux.
Je crains de perdre des données avec pgloader si une telle manip doit être automatisée.
Ce que je cherche, c'est le maillon final pour cette chaine :
Fetchmail ---> Procmail ---> Postgres
au lieu de :
Fetchmail ---> Procmail ---> fichier plat--->Phppgadmin--->Postgres
Est-ce envisageable avec pgloader sans interruption de flux ?
Fetchmail ---> Procmail ---> fichier plat--->pgloader--->Postgres
Merci beaucoup. Je vais regarder ça.
Bonjour le forum,
Actuellement mes recettes Procmail remplissent un fichier en texte délimité que j'importe ensuite avec PhpPgAdmin
Je souhaite automatiser ce remplissage.
Que me conseilleriez-vous pour que mes recettes Procmail puissent remplir une table Postgres à la volée?
Je ne parle aucun langage de programmation sauf quelques mots en PHP, en BASH et un peu plus en SQL.
Merci par avance.
La version la plus récente du connecteur ODBC pour PG 8.2 est : psqlodbc-08_02_0500.zip
Bonjour et merci beaucoup pour la réponse mais avec les drivers pour 8.2 j'ai un message d'erreur (*).
Avec le plus récent driver de la 8.1 j'ai connecté NT4-SP6/MS Access 2000 sur une base PostgreSQL 8.2 (voir le post initial du 25/09).
Malheureusement les déconnexions sont systématiques.
Je n'ai pas encore réussi à identifier dans quelles conditions celles-ci se produisent.
(*) "Ce package d'installation ne peut pas être installé par le service Windows installer. Vous devez installer un service pack Windows contenant une version plus récente du service Windows Installer".
Bonjour,
Moi, je commencerai par m'assurer de l'état des ports ouverts sur le serveur :
$ nmap l'ip-du-serveur
[...]
5432/tcp open postgres
Alors voilà, les présentations étant faites, avant de me lancer progressivement dans la migration, je voudrai avoir votre avis sur la dernière version du driver ODBC pour Access. La version est dans le titre.
Les deux drivers ci-dessous n'ont pas pu s'installer sur NT4.
Motif : installateur trop vieux pour la version du Service Pack.
- psqlodbc_08_03_0200.zip
- psqlodbc-08_02_0400.zip
En remontant dans le temps, celui-ci s'est bien installé :
- psqlodbc-08_01_0200.zip
Il m'a au moins permis d'établir la connexion.
Est-ce bien la plus haute version disponible?
Est-ce que je peut partir sur cette configuration?
A cause des limitations dûes à ODBC, les précautions que je dois prendre sont :
- nouvelle base Access,
- présence d'une colonne serial dans les tables Postgres
- quoi d'autre que je ne connaît pas encore?
Merci par avance.
Bonjour à tous,
Ceci est mon tout premier post sur ce forum alors je me présente :
- faux débutant en bases de données.
- non programmeur.
- une base de donnée MS Access partagée à 2/3 personnes à migrer.
- tentatives initiales avortées Mysql, OObase, Kexi. Choix Postgres.
- reste à trouver une interface graphique pour mettre à jour les données à la volée.
- inquiet quand au chemin à parcourir sur l'interopérabilité (mot à la mode sur les formats bureautique) entre les différentes bases du Libre.
Je ne peux pas me permettre d'attendre d'être "au point" avec Postgres/php/html pour tout migrer en une seule fois, ce qui aurait évité de passer par un connecteur.
