Vous n'êtes pas identifié(e).
...because you and another user are attempting to change the same data at the same time.
Voilà le message que j'obtiens alors que je suis seul à travailler sur cette base de données.
Il s'agit d'un recordset dont je mets à jour un record.
Sur le net, j'ai trouvé des pages qui mettent en cause des champs boolean ou timestamp mais ce n'est pas le cas ici.
Avez-vous une petite idée ?
Merci
Hors ligne
Non mais ce n'est pas très étonnant vu que c'est un forum sur PostgreSQL.
Guillaume.
Hors ligne
Oui et non parce que c'est une migration d'Access vers PG. Le front-end reste en Access. Connaissez-vous une application cliente aussi bonne qu'Access/VBA pour PG ?
Hors ligne
Ce n'est pas vraiment la question. Vous avez un message d'erreur Access. Nous ne pouvons pas grand chose pour vous. À part si vous avez un message d'erreur aussi dans la log de postgres qui nous permettrait d'y voir un peu plus clair.
Marc.
Hors ligne
Je crains que la solution du problème soit du côté PG.
J'ai implementé un delete logique au moyen d'un trigger pre delete qui met à jour un champ du record.
Voici un morceau du trigger function :
stmt := 'update public.'
|| quote_ident(TG_TABLE_NAME)
|| ' set deleted_when = now() ,deleted_by = '
|| ''''
|| current_user
|| ''''
|| ' where ';
case TG_TABLE_NAME
when 'tblActions_data' then
stmt := stmt || '"ActionID" = $1;';
execute stmt using old."ActionID";Si je disable le trigger, le problème est résolu. N'y aurat-il pas moyen de dire à la fonction de ne pas envoyer de message au front-end ?
[
Hors ligne
Si vous n'avez pas de problème sans le trigger, c'est que le trigger est le problème. Maintenant, avec juste un bout de code, je ne vois pas comment on pourrait aller plus loin... surtout quand on n'utilise pas Access (ce qui est mon cas et celui de Marc, je suppose).
Guillaume.
Hors ligne
because you and another user are attempting to change the same data at the same time
Je crois me souvenir qu'Access avec ODBC détermine ça par le fait que les valeurs qu'il relit d'une ligne lors d'une demande de mise à jour ne sont pas les mêmes que celles qu'il a trouvé quand il a l'a lu précédemment.
Donc de son point de vue, un trigger qui change la valeur d'une colonne, c'est "another user".
C'est aussi pour ça que cette erreur peut survenir sur certains de types de données un peu exotiques, pour lesquels parfois Access ne reconnait pas ce que lui-même a mis dans la table après relecture et réinterprétation via la couche ODBC.
PS: il faut bien voir qu'un système d'historisation "soft-delete" qui transforme carrément les DELETE en UPDATE est très intrusif et surprenant pour le côté client. Le fait qu'Access/ODBC soit paumé n'est qu'une conséquence parmi d'autres de cette méthode.
Personnellement je préfère sans hésiter un système qui historise les lignes effacées en les copiant dans d'autres tables, comme mentionné dans une discussion précédente qui concernait vraisemblablement le même projet:
http://forums.postgresql.fr/viewtopic.php?id=4146
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Cher Monsieur Vérité,
Une fois de plus, vous apportez la lumière dans les ténèbres.
De fait, je suis passé à un système qui historise les records deletés dans un autre schema et qui les delete pour de bon dans le schéma public.
Ceci dit, Access en front-end d'un db pg marche bien.
Une fois de plus, un grand merci à vous. Et à Guillaume, bien sûr.
Bonne soirée à tous les deux
Hors ligne
Voici le trigger qui historise dans le schema 'deleted' qui contient toutes les tables du schema public et qui sont vides à l'origine des temps :
CREATE OR REPLACE FUNCTION public.audit_d()
RETURNS trigger AS
$BODY$
declare
stmt varchar;
begin
insert into public.audit_history
(table_name, operation, audit_id, user_name, audit_date)
values
(TG_TABLE_NAME, TG_OP, old.audit_id, current_user, now());
stmt := 'insert into deleted.'
|| quote_ident(TG_TABLE_NAME)
|| ' select * from public.'
|| quote_ident(TG_TABLE_NAME)
|| ' where audit_id = $1;';
execute stmt using old.audit_id;
return old;
end; Hors ligne