Sujet: Vider la base 4.031

[AquaBlue]

J'essaye de vider une base 4.031 (V511) et j'obtiens un message :

attempted update of read-only column

At trigger 'TBD-EVENEMENTS_IND

At trigger 'CHECK_3'

[DDdeBerdeux]

Bonjour,

Excuse le retard à te répondre, mais je viens de découvrir ton message, que le forum ne m'a pas signalé comme nouveau.

V513 b4.031, FB serveur 1.5.3 local, j'ai fait l'expérience sans rencontrer de problème. Après avoir vidé la base, j'ai choisi de réimporter un gedcom tout à fait normalement.

TBD_EVENEMENTS_IND est un trigger qui va faire le ménage dans les tables SOURCES_RECORD, MEDIA_POINTEURS et T_ASSOCIATIONS avant qu'on supprime un évènement individuel.

CHECK_3 est un trigger système déclenché sans doûte par le vidage de la table DOSSIER (intégrité référentielle avec le champ EV_IND_KLE_DOSSIER, parfaitement inutile par ailleurs).

Je ne vois pas d'explication au problème car justement les procédures PROC_VIDE_BASE, PROC_VIDE_TABLE, PROC_VIDE_DOSSIER, PROC_VIDE_BIBLIO ont été modifiées dès la version b4.00.

Pourrais-tu vérifier que dans ta base, PROC_VIDE_BASE a bien été modifiée le 30/10/2005, et que DOOSIER est bien la dernière table vidée?

Le problème s'est-il reproduit depuis?

A+

André

[AquaBlue]

Pas de problème pour le délais, mon message ci-dessus était plus pour information que pour obtenir de l'aide.



En fait je n'ai pas vraiment cherché   Comme j'avais juste besoin d'une base vide pour tester l'import du GEDCOM de milesi, j'ai téléchargé la base vide (point 9) et suis reparti avec elle.



Oui les PROC_VIDE_xxx ont été mises à jour entre 10/2005 et 02/2006.

Oui VIDE_BASE est OK et DOSSIER est bien la dernière table.

Le problème est systématique avec cette base.



Je viens de faire des tests en repartant d'une base 3.57

La base en 3.57 peut être vidée sans problème.

Je la passe en 4.031 avec maj_b357_b4031.exe et là elle n'est plus vidable et me donne très exactement l'erreur dont j'ai donné le message ci-dessus.



Ooops ! j'ai oublié de préciser V500 et Firebird 2.0.0.12169 (c'est peut-être lui le fautif !?)

[AquaBlue]

Comme j'ai encore les exe de maj de la base, j'ai fait quelques tests complémentaires:

3.57 => 4.010 vidage OK

3.57 => 4.012 vidage OK

3.57 => 4.015 vidage OK

3.57 => 4.017 vidage KO



j'ai encore 4.022, 4.025 et 4.028 que je n'ai pas testé car je suppose qu'ils embarquent aussi les modifs de la 4.017

[AquaBlue]

J'ai poursuivi les tests.



Pas de problème avec la base vide du point 9    



Voici les differences que j'ai trouvées entre les deux bases 4.031 (migrées 3.57=>4.031 et celle chargée au point 9)



PROC_MAJ_POUR_MEDIAS n'existe pas dans ma base migrée 3.57=>4.031



AI_T_IMPORT_GEDCOM_IG en plus dans la base migrée 3.57=>4.031

INDIVIDU_AU en plus dans la base migrée 3.57=>4.031



UDF je n'ai pas SUBSTLEN dans la base migrée 3.57=>4.031



Les index suivants sont en plus

RDB$PRIMARY39

RDB$PRIMARY40

RDB$PRIMARY41

RDB$PRIMARY42

RDB$PRIMARY43

RDB$PRIMARY44 dans la base migrée 3.57=>4.031



Pour PCM trois remarques :

- la sélection d'une nouvelle base est d'une lenteur étrange.

- quand la base est vide le caption de la fenêtre ne donne pas les versions.

- enfin, le plus grave, aprè un échec de connexion TOUS les menus sont grisés y compris celui qui permettrait de choisir une nouvelle base. Je pense que ce point est la cause de beaucoup des appels "Au secours ! J'ai perdu ma base."

[DDdeBerdeux]

Bon, j'avais fait le tour avant de recevoir ton dernier message:

Pas de problème avec FB 1.5.3.

Problème avec FB 2.0, version que j'utilise sur mon serveur Linux.

Les raisons: on s'en est aperçu, si tu te souviens du pb de la dll Cassinivision, et d'autres modifications que j'ai dû faire en b4.029, que FB2.0 est beaucoup plus pointilleux sur la syntaxe. Il rejette le trigger:

Code: [Sélectionner]

CREATE TRIGGER "INDIVIDU_AU" FOR "INDIVIDU"

ACTIVE AFTER UPDATE POSITION 0

AS

BEGIN

  /* Trigger body */

    NEW.DATE_MODIF = 'NOW';

ENDavec raison, parce qu'on ne peut modifier une table après l'avoir écrite, mais que FB1.5 ignorait. C'est la raison du message "colonne en lecture seule".  Je l'avais d'ailleurs viré depuis longtemps de ma propre base et de la base vide que je met en ligne sur mon site lors des tests. C'est la raison pour laquelle ce trigger ne figure pas sur la base seule en ligne sur le site.

Pour rechercher les incompatibilités avec FB2.0 pour la b4.029, j'avais recompilé toutes les métadatas, mais comme comme je n'avais déjà plus ce trigger... J'en mettrais le drop dans la prochaine version de la base.

En attendant pour te dépanner exécute: DROP TRIGGER INDIVIDU_AU. Chez moi çà a suffit pour que la base se vide sans erreur. Si le problème persiste, fait un backup/restore.

Pour le reste:

PROC_MAJ_POUR_MEDIAS ne devrait pas être dans la base. C'est une procédure créée à partir de la b4.005 afin de corriger les erreurs concernant la gestion des medias dans la base. Le script la crée, l'exécute et la supprime. Elle ne reste pas dans les bases mises à jour, mais pourquoi est-elle sur la base du point 9

AI_T_IMPORT_GEDCOM_IG est un trigger ajouté par le logiciel (en v490? lors de la création de la fonction de suppression d'un import). Comme il est parfaitement inutile, je ne l'ai pas mis dans la base vide.

SUBSTLEN est une fonction externe inutilisée.

Quand aux index primaires, je ne les retrouve dans aucune de mes bases, mêmes des b3.57 fraîchement migrées en b4.031. Une optimisation les ferait-elle disparaître? Quelles sont leur définitions?

Dernier point, puisque tu utilises la version FB2.0, l'option d'optimisation d'Ancestrologie fonctionne-t-elle encore? Comme je n'ai pas vu que gback.exe faisait partie de FBembedded, PCM a je pense intégré une version de gback dans ancestrologie.exe. Fonctionne-t-elle avec FB2.0?

Attention pour faire l'essai, une base optimisée avec le gback de FB2.0 ne fonctionne plus sous FB1.5.

A+

André

[AquaBlue]

C'est bien INDIVIDU_AU qui posait problème.

Après l'avoir viré je peux vider la base sans problème.



Les index ne correspondent à aucun champ connu de la base donc probablement des scories à supprimer. (L'optimisation ne les a pas supprimer)



Je ne sais pas où est le GBACK mais je confirme que l'optimisation fonctionne sans souci avec 2.0 beta 2

Et j'ai très nettement l'impression que ça va beaucoup plus vite.

De même le temps d'export GEDCOM semble aussi plus court avec 2.0

[DDdeBerdeux]

Comme confirmation, 2 points relevés dans "README.incompatibilities.txt" de FB2.0, qui mentionnent des anomalies de la base que FB2.0 n'accepte plus (elles ont normalement été corrigées depuis b4.029).

Code: [Sélectionner]

SQL CHECKING

--------------------------

  * It's now prohibited to reference columns of an aliased table using the table

    name, e.g. "SELECT TAB.A FROM TAB T". You should use the table alias

    instead: "SELECT T.A FROM TAB T". Such behaviour is declared by the SQL

    specification.



  * Assignments to OLD contexts are now prohibited for all kinds of triggers.

    Also, assignments to NEW contexts in AFTER-triggers are prohibited as well.

    So, if you get an unexpected error "cannot update a read-only column", this

    is exactly the reason.On y retrouve bien l'erreur que tu signalais.

As-tu essayé d'utiliser la base optimisée par ancestrologie, sous FB1.5.3 (avec la version embedded pour tester)?

Pour ma part, FB2.0 fonctionnant sur un serveur réseau, l'option d'optimisation d'ancestrologie (tout comme la sauvegarde) est inutilisable. Je suis obligé de passer par un backup/restore sur le serveur, utilisant donc le gback de FB2.0. Après celà la base ne peut plus être utilisée sur le poste windows utilisant FB1.5.3, la structure du fichier ayant été modifiée.

A+

André

[AquaBlue]

Non je n'ai pas essayé.



Il faut dire que j'ai viré embeded il y a très, très longtemps et que j'ai désinstallé 1.5 avant d'installer 2.0