Vous n'êtes pas identifié(e).
Pages : 1
soit en utilsant la table que j'ai écris precedement
INSERT INTO emp_audit SELECT 'U', now(), user, OLD.nom_employe,OLD.salaire,NEW.nom_employe,NEW.salaire
Apres vous pouvez adapter en concatenant les valeurs (si c'est vraiment votre besoin), mais cela peut etre moins pratique pour les recherche
INSERT INTO emp_audit SELECT 'D', now(), user, OLD.nom_employe||';'||OLD.salaire::text,NEW.nom_employe||';'||NEW.salaire::text
avec cette table
CREATE TABLE emp_audit(
operation char(1) NOT NULL,
tampon timestamp NOT NULL,
id_utilisateur text NOT NULL,
employe_old text ,
employe_new text
);
edit: petit oubli ^^
en testant les valeurs null sinon la concatenation avec du null, ce n'est pas terrible
case when OLD.nom_employe is null then '(null)' else OLD.nom_employe end||';'||case when OLD.salaire is null then '(null)'::text else OLD.salaire::text end
même chose a faire pour le new
Bonjour,
Pour cela il faut que vous recreez la requete.
en testant et concatenant les differentes valeurs contenues dans NEW et OLD.
si old.nom_employe est null alors il s'agit d'un INSERT
si new.nom_employee alors c'est un DELETE
pour les autres cas UPDATE
Apres vous reconstituez l'instruction, le probleme c'est que vous ne recuperez pas le where surtout si cela touche plusieurs records avec une seule requete, donc pas tres utilisable.
Le mieux est de stocker les anciennes valeurs (OLD) et les nouvelles (NEW) pour chaque lignes impactées par la requete
CREATE TABLE emp_audit(
operation char(1) NOT NULL,
tampon timestamp NOT NULL,
id_utilisateur text NOT NULL,
nom_employe_old text ,
salaire_old integer,
nom_employe_new text ,
salaire_new integer
);
Je ne comprends pas trop la question.
Pour cela j'effectuerai un ou des batchs/shell
pour sauvegarder seulement un schema à partir du server
pg_dump -U login -n monshema1 -Fc basedb > /home/svg_monschema1.dump
Il y a une raison particuliere pour que vous vouliez declencher la sauvegarde à partir de votre poste en local.
Sinon vous pouvez aussi lancer directement la sauvegarde à partir de votre poste local en renseignant les infos de connections dans le pg_dump.
Lancez pgadmin de votre poste local et effectuez une sauvegarde avec, vous verrez la ligne de commande utilisée.
Vous voulez "log" toutes les requêtes provisoirement (pour debugger ou autre) ou tout le temps même en environnement de production ?
Car dans le premier cas, il est possible d'utiliser le fichier log de postgres (qui sera capable de logger toutes les requetes passées ou supérieur à un certain temps d'execution voir : log_min_duration_statement dans le fichier posgresql.conf)
Celui ci ce configure dans le fichier postgresql.conf (section ERROR REPORTING AND LOGGING)
Par contre ce moyen est tres pratique pour le debuggage, mais ralentit les performances. C'est pour cela que je ne l'utilise ou active que ponctuellement.
Pour l'autre méthode expliquée dans votre post, il s'agit de creer une table avec les champ que vous voulez renseigner ou suivre.
avec des champs du style ( timestamp pour la date heure, type de requete "insert","update","delete" et la table impactée) par contre je ne pense pas qu'on pourra recuperer la requete sql en commande.
Au mieux récuperer l'ancienne valeur et la nouvelle valeur des records. En utilisant les valeurs new et old qu'on peut cumuler dans deux champs.
Après on place des trigger sur les tables concernées, qui vont remplir cette table log.
(Je dois avoir un script de ce genre avec un trigger sur une table cela pourra etre une bonne base pour l'adapter à plusieurs table, si c'est bien ce que vous voulez faire.)
Sinon vous avez un autre moyen, si vous passez par server d'application (par ex: jonas) vous pouvez logger à partir celui ci, ce qui permet aussi d'avoir les requetes qui ne modifient pas les enregistrements.
update exemple.parcelles_annecy SET bati_ok=true
where id_parc in( select id_parc from exemple.parc_annecy_bati )Bonjour,
Pour éviter les plaintes ou cris d'un développeur qui aurait "dropé" une vue par "erreur" (un drop cascade malheureux d'une table, un mauvais create or replace view et impossible de se rappeler ce qu'on avait avant, une disparition inexpliquée ou la mauvaise foi tout simplement 
...)
Enfin les raisons peuvent être multiples.
Biensur nous avons toujours une sauvegarde sous la main, mais bon parfois cela ne suffit pas ou peut être une perte de temps pour le dba (surtout en fonction du nombre de dev)...
Donc voila voulant les rendre plus autonome, en cas de problème.
J'ai mis ce petit script en place, qui permet de sauvegarder les modifications de définition d'une vue dans une table à une fréquence donnée (à définir dans le cron pour le lancement du script chez moi il est toute les 10 min sur les serveurs de dev).
1- Creer la table suivante
CREATE TABLE backup_views
(
backup_date timestamp with time zone,
base text,
table_schema text,
table_name text,
view_definition text,
create_script text
);2- Creer un fichier batch backupview.sh sur le serveur
contenant le code suivant
#!/bin/bash
psql -U postgres -c "insert into backup_views
select current_timestamp as backup_date,n.table_catalog as base,n.table_schema::text,n.table_name::text,n.view_definition::text ,
'CREATE OR REPLACE VIEW '||n.table_schema||'.'||n.table_name||' as '||n.view_definition||';'::text as create_script
from information_schema.views n where n.table_schema not in ('information_schema','pg_catalog')
and (n.table_catalog,n.table_schema,n.table_name,n.view_definition) not in
(select base,table_schema,table_name,view_definition from backup_views where (backup_date,base,table_schema,table_name) in
(select max(backup_date),base,table_schema,table_name from backup_views group by base,table_schema,table_name));" infoctr > /dev/null(infoctr est le nom de la base, à remplacer par la votre)
Reste à le planifier dans le cron du serveur
Au premier lancement toutes les definitions de vues seront sauvegardées dans la table backup_views, ensuite seulement les nouvelles vues ou vues modifiées seront ajoutées.
(Remarque: juste la definition de la vue est sauvegardée, il n'y a pas les ACL dans cette version)
Voila si ce petit retour peut servir ou augmenter l'esperance de vie des developpeurs.
PS: Je ne sais pas si je suis dans la bonne rubrique, c'est plus un retour d'experience, astuce, enin bon...
Je ne connais pas ora2pg, peut etre à t-il besoin d'avoir acces directement à des informations se trouvant dans le pg_catalog. dans ce cas il faut lui ajouter dans search_path surtout si les requetes générées par ora2pg utilisent des objets dans pg_catalog (sans prefixer l'objet).
pg_catalog est un schema "correspondant" au schema sys d'oracle, vous trouverez un tas d'informations (trés utiles) sur les objets de la base données.
Le schema public, lui est un schema par défaut (peut etre pratique pour partager des objetcs, pouvant etre utilisés par differents users qui ont leur propre schema. quoique dans mon cas je crée un schema common pour cela, mon public est vide , non je ne suis pas un maniaque du rangement )
Bonjour,
Pour "coller" au mieux au mode de fonctionnement d'oracle, car en oracle la notion de schema est liée au user.
En postgres ces 2 notions sont distinctes.
Il serai bien de créer aussi un utilisateur (base de donnée) cardplus (même nom que le schema)
CREATE ROLE cardplus LOGIN
NOSUPERUSER NOINHERIT NOCREATEDB NOCREATEROLE;Mise a jour du search path de ce user cardplus:
ALTER ROLE cardplusSET search_path=cardplus, public;lui donner l'autorisation sur le schema cardplus
GRANT ALL ON SCHEMA cardplusTO cardplus;Comme cela en vous connectant en cardplus, son schema par defaut sera cardplus.
(Attention si vous avez deja créé des objets avec l'utilisateur postgres dans ce schema, pensez à changer l'owner de ceux ci est de les mettre en cardplus
en se connectant en postgres faire :
ALTER TABLE cardplus.objetx OWNER TO cardplus;)
Pages : 1