Noalyss

Bonsoir,

non, je n\'ai pas de souvenir d\'avoir lancé de script sql directement. Si je suis très à l\'aise pour le faire sur une base MySQL, c\'est mon premier contact avec PostgreSQL. La seule opération que j\'ai effectuée a été de lancer l\'upgrade de la version 8 vers la version 9.1.

J\'ai bien été lire des scripts pour essayer de comprendre ce qui se passe, mais je me suis rendu compte en investigant le code php (suivant les messages d\'erreur) que ces script n\'entraient pas en ligne de compte.

Que me conseilles tu de faire? Je peux me passer du module amortissement, mais c\'est un peu dommage. Y at\'il moyen de créer/updater la clé manquante, ou alors mieux vaut\'il de recréer une base toute nouvelle au 1er janvier 2013 et abandonner ce que j\'ai fait cette année (c\'est la première année comptable pour moi).

Merci pour le support.

Jean Pierre

Il y a 2 possibilités :
a) création des deux clef qui manquent
b) vérification de toute la structure, parce que franchement c\'est bizarre que la contrainte aie disparu, note que cela fonctionne correctement avec postgresql 9.2

Personnellement je ferais le a) pour passer le problème mais tôt ou tard, je devrais me taper le b)


Si tu tapes la commande Tu dois avoir 166 contraintes (voir liste) dans la colonne contype
P = clef primaire
c = check
u = unique
f = foreign key [file name=constrainte.txt size=7805]http://www.phpcompta.be/images/fbfiles/ ... rainte.txt[/file]

Bonjour,

J\'espère que vous aves passé de bonnes fêtes de noël.

J\'ai lancé la query proposée et j\'obtiens 167 contraintes (une de plus).
Voir le fichier attaché.

Par contre, comment puis-je savoir quelles sont les clés manquantes?
Et comment puis-je procéder à l\'analyse de toute la structure? Existe-t\'il un script de vérification?

Merci
Jean Pierre [file name=phpcomptaConstraints.txt size=4112]http://www.phpcompta.be/images/fbfiles/ ... raints.txt[/file]

L\'erreur vient de Ce qui me tracasse c\'est qu\'il y a une clef unique pour cette table. C\'est vraiment bizarre.

Avec pgAdmin3, pourrais-tu regarder quel est le script pour cette table ?

Essaie un peu cette commande

Bonsoir,

bien vu, effectivement cette table n\'a pas de clé primaire

voici le script associé à la table:

-- Table: tmp_pcmn

-- DROP TABLE tmp_pcmn;

CREATE TABLE tmp_pcmn
(
pcm_val account_type NOT NULL,
pcm_lib text,
pcm_val_parent account_type DEFAULT 0,
pcm_type text
)
WITH (
OIDS=TRUE
);
ALTER TABLE tmp_pcmn
OWNER TO phpcompta;
COMMENT ON TABLE tmp_pcmn
IS \'Plan comptable minimum normalisé\';

Et dans les propriétés il est mentionné \'no primary key\'.
Je vais donc lancer l\'instruction proposée.

A plus
Jean Pierre

Ou alors ajoute la clef primaire sur pcm_val, ce serait encore mieux

Bonsoir,

je viens de découvrir la chose suivante.
Sur la base de donnée de ma compta \'officielle\' voici le script de la table en question:

-- Table: tmp_pcmn

-- DROP TABLE tmp_pcmn;

CREATE TABLE tmp_pcmn
(
pcm_val account_type NOT NULL,
pcm_lib text,
pcm_val_parent account_type DEFAULT 0,
pcm_type text,
CONSTRAINT tmp_pcmn_pkey PRIMARY KEY (pcm_val )
)
WITH (
OIDS=TRUE
);
ALTER TABLE tmp_pcmn
OWNER TO phpcompta;
COMMENT ON TABLE tmp_pcmn
IS \'Plan comptable minimum normalisé\';

-- Trigger: t_tmp_pcm_alphanum_ins_upd on tmp_pcmn

-- DROP TRIGGER t_tmp_pcm_alphanum_ins_upd ON tmp_pcmn;

CREATE TRIGGER t_tmp_pcm_alphanum_ins_upd
BEFORE INSERT OR UPDATE
ON tmp_pcmn
FOR EACH ROW
EXECUTE PROCEDURE comptaproc.tmp_pcmn_alphanum_ins_upd();

-- Trigger: t_tmp_pcmn_ins on tmp_pcmn

-- DROP TRIGGER t_tmp_pcmn_ins ON tmp_pcmn;

CREATE TRIGGER t_tmp_pcmn_ins
BEFORE INSERT
ON tmp_pcmn
FOR EACH ROW
EXECUTE PROCEDURE comptaproc.tmp_pcmn_ins();

La clé primaire est bien présente.

Je fais un backup de cette base et je la restaure et voici le script lié à cette même table.

-- Table: tmp_pcmn

-- DROP TABLE tmp_pcmn;

CREATE TABLE tmp_pcmn
(
pcm_val account_type NOT NULL,
pcm_lib text,
pcm_val_parent account_type DEFAULT 0,
pcm_type text
)
WITH (
OIDS=TRUE
);
ALTER TABLE tmp_pcmn
OWNER TO phpcompta;
COMMENT ON TABLE tmp_pcmn
IS \'Plan comptable minimum normalisé\';

La clé primaire a disparu et les triggers aussi. Or à ce jour, je n\'ai testé les amortissement que sur des backups car je ne savais pas si je n\'allais pas faire de bétise dans ma compta officielle. Je me demande si je n\'ai pas mis le doigt sur un bug important, car du coup mon backup ne m\'inspire pas confiance...

Peut-être que en utilisant le module amortissement sur ma base \'officielle\' il va marcher correctement.

Qu\'est ce que tu en penses?

Merci pour le support

Jean Pierre

Bonsoir,

je confirme, tout marche bien pour ma comptabilité \'officielle\', par contre dès que je veux retravailler un backup, même celui sur lequel l\'amortissement a fonctionné, plus moyen d\'obtenir le détail des années pour une nouvelle fiche à amortir.

J\'espère que cela va servir.

Bonne nuit

Jean Pierre

Bonsoir,

Le problème est très curieux : en fait, phpcompta appele une fonction de postgresql (pg_dump) pour faire ses backups, donc le bug n\'est pas dans phpcompta mais dans postgres

Combien de version de postgresql as-tu sur ta machine ? Ma théorie est que tu appeles une version plus ancienne pour les backups et celle-ci fait mal les backups.

Pour contourner ce problème, tu peux faire un backup avec pgadmin3 (ou la commande pg_dump) puis restaurer.

Le problème est intéressant en tout cas.

Le plus simple est de faire un backup / restore en ligne de commande, ainsi on verra directement ce qui s\'est passé.

des tits liens pour aider

http://docs.postgresqlfr.org/9.1/app-pg-dumpall.html

http://docs.postgresqlfr.org/9.1/backup.html

Voici le message reçu en faisant pg_dump avec phpcompta comme utilisateur et aucune autre option:

pg_dump: error reading large object 34120: ERROR: permission denied for large object 34120

J\'obtiens bien un fichier de taille comparable à ceux réalisé par phpcompta, mais je n\'ai pas essayé de le restaurer.

Jean Pierre