Discussion :

[engi]

Bonjour,

Je reviens avec mon problème de mise à jour de la structure de ma base de données.
Quand je distribue une nouvelle version de ma base de données, cette dernière nécessite une série de modifications sur une ou plusieurs tables.

Une des dernières MAJ ressemble à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
ALTER TABLE MOD_NIL ADD NIL_TECHNO SMALLINT DEFAULT 3;
UPDATE MOD_NIL SET NIL_TECHNO = 3;
 
ALTER TABLE MOD_NIL ADD NIL_TECHNO_DIGITS SMALLINT;
UPDATE MOD_NIL SET NIL_TECHNO_DIGITS = 26;
 
ALTER TABLE MOD_NIL ADD NIL_TECHNO_MODE_ETENDU SMALLINT DEFAULT 0;
UPDATE MOD_NIL SET NIL_TECHNO_MODE_ETENDU = 0;

Mon soucis, c'est qu'apparemment, chaque instruction 'ALTER' demande un COMMIT avant que l'instruction 'UPDATE' puisse être exécutée.

Faire un COMMIT à répétition ne me pose pas de problème.
En revanche, comment m'assurer que toutes les modifications pourront être annulées en cas d'erreur, par exemple, sur la dernière modif ?

[Yanika_bzh]

Normalement si vous utilisez l'option DEFAULT pour declarer vos colonnes, il n'est pas necessaire d'effectuer un UPDATE ensuite.

Cela me surprend que vous devez commiter un ALTER.
Quel est votre SGBD ??

Bon courage

[engi]

j'utilise firebird.
pour ce qui est du DEFAULT, je vérifie et je vous tiens au courant.

[engi]

non, le DEFAULT n'initialise pas la valeur de la nouvelle colonne pour les enregistrements existants.

si je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
ALTER TABLE MOD_NIL ADD NIL_TECHNO SMALLINT DEFAULT 3;
- exécution commit -
UPDATE MOD_NIL SET NIL_TECHNO = 3;
- exécution commit -

ça fonctionne !

par contre, si je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ALTER TABLE MOD_NIL ADD NIL_TECHNO SMALLINT DEFAULT 3;
UPDATE MOD_NIL SET NIL_TECHNO = 3;
- exécution commit -

j'obtiens le message d'erreur suivant à l'éxécution du UPDATE:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Column does not belong to referenced table.
Dynamic SQL Error.
SQL error code = -206.
Column unknown.
NIL_TECHNO.
At line 1, column 20.

[ITCsoft54]

Apres ton alter table quand tu liste les colones de ta table tu vois les changement ?
Ton SGBD oblige peut etre Un commit sur apres un alter table pour eviter que les autres users aient un probleme lors de l'execution de requete sur la base.

Tu peux verifier de si tu est 'autocommit', je ne connais pas bien firebird mais cette option doit exister.

[engi]

Apres ton alter table quand tu liste les colones de ta table tu vois les changement ?
Ton SGBD oblige peut etre Un commit sur apres un alter table pour eviter que les autres users aient un probleme lors de l'execution de requete sur la base.

Tant que je n'ai pas fait le commit, la modification de structure n'apparait pas dans la base pour les autres clients.

Tu peux verifier de si tu est 'autocommit', je ne connais pas bien firebird mais cette option doit exister.

Avec les composants que j'utilise, j'ai effectivement la possibilité de programmer un autocommit, mais justement, c'est cela que je veux éviter.
Je veux pouvoir ne faire le commit qu'à la fin de toutes les modifs.

[SQLpro]

Vous tentez de passer 2 ordres SQL là ou le système n'est capable de n'en traîter qu'un seul à la fois. Intéressez vous à SET TERM dans Interbase qui permet de délimiter chaque ordre SQL.

A +

[engi]

Bonjour,

Mon exemple est peut-être trompeur.
En fait, mon client est écrit en c++ et il utilise des composants dédiés (FIBPlus) pour 'dialoguer' avec le sgbd.
Chaque ordre est bien envoyé séparément et c'est justement à l'exécution du second envoi que l'erreur est renvoyée par Firebird.

[ITCsoft54]

L'erreur renvoyer viens peut être du fait que tu n'utilise pas la même connexion entre deux appels. Du coup la modification que tu n'est pas visible, ce qui semble être ton cas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
COLUMN unknown.
NIL_TECHNO.
At line 1, COLUMN 20.

Ce qui semble bizarre c'est que tu envois le commit de la même manière, du coup je comprend pas vraiment pourquoi au deuxième appel la connexion serait différente.

Tu devrais chercher dans la doc de ta library, je pense que c'est plus un problème de programmation que de SQL.

[engi]

avant tout, merci à ceux qui suivent ou participent à ce fil.

pour répondre à ITCsoft54, oui, j'utilise bien la même connexion.
alors oui, c'est peut être un problème lié aux composants que j'utilise.

je vais tenter de faire les même manips avec autre chose pour en avoir le coeur net.