Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Philippe T [MS]
Bonjour,
Pouvez-vous m'expliquer l'intéret d'avoir deux fois la même info au sein de la même table (identity ou pas d'ailleur) ???
Phil. ________________________________________________________ Philippe TROTIN http://blogs.msdn.com/ptrotin Microsoft Services France http://www.microsoft.com/france
"Jean-Francois Courteau" wrote in message news:OH$
Comment faire pour éviter d'utiliser une instruction update utilisant le retour du @@identity après avoir exécuté l'insertion ?
Merci d'avance Jean-François Courteau
Bonjour,
Pouvez-vous m'expliquer l'intéret d'avoir deux fois la même info au sein de
la même table (identity ou pas d'ailleur) ???
Phil.
________________________________________________________
Philippe TROTIN http://blogs.msdn.com/ptrotin
Microsoft Services France http://www.microsoft.com/france
"Jean-Francois Courteau" <jfcourteau@boxisp.com> wrote in message
news:OH$oYKe5EHA.208@TK2MSFTNGP12.phx.gbl...
Comment faire pour éviter d'utiliser une instruction update utilisant le
retour du @@identity après avoir exécuté l'insertion ?
Pouvez-vous m'expliquer l'intéret d'avoir deux fois la même info au sein de la même table (identity ou pas d'ailleur) ???
Phil. ________________________________________________________ Philippe TROTIN http://blogs.msdn.com/ptrotin Microsoft Services France http://www.microsoft.com/france
"Jean-Francois Courteau" wrote in message news:OH$
Comment faire pour éviter d'utiliser une instruction update utilisant le retour du @@identity après avoir exécuté l'insertion ?
Merci d'avance Jean-François Courteau
Jean-Francois Courteau
Ce fut aussi ma réaction lorsque j'ai constaté la documentation qui me fut fournise pour procéder au transfert des données de la source vers cette nouvelle db conçue par un consultant externe. Soit de me demander pourquoi duppliquer un champ. Il sagit d'un lien interne à cette table. En fait ce même déccor se retrouve en chacune de ces tables de son système. Selon son explication, ce mécanisme sert à des fins d'historique des données. Disons que l'on parle d'une table de clients, le premier enregistrement concernant un client donné retrouvera la valeur de sa clé duppliqué au sein d'un champ qui est en liaison interne avec la clé de la table. Si une modification à lieu, une nouvelle insertion est faite et le nouvel enregistrement se voit recevoir la valeur de la clé de l'enregistrement initial concernant le client au sein du champ lié à la clé primaire. Ce champ sert donc à retrouver toute les occurences formant l'historique d'un client. Ce n'est pas ce que j'aurais appliqué pour obtenir le même résultat mais ca reste justifiable comme façon de faire. Par contre ca me force à une requête de mise à jour après mes insertions au transfert vers son système ce qui ralenti de beaucoup mon processus.
Jean-François Courteau
Ce fut aussi ma réaction lorsque j'ai constaté la documentation qui me fut
fournise pour procéder au transfert des données de la source vers cette
nouvelle db conçue par un consultant externe. Soit de me demander pourquoi
duppliquer un champ. Il sagit d'un lien interne à cette table. En fait ce
même déccor se retrouve en chacune de ces tables de son système. Selon son
explication, ce mécanisme sert à des fins d'historique des données. Disons
que l'on parle d'une table de clients, le premier enregistrement concernant
un client donné retrouvera la valeur de sa clé duppliqué au sein d'un champ
qui est en liaison interne avec la clé de la table. Si une modification à
lieu, une nouvelle insertion est faite et le nouvel enregistrement se voit
recevoir la valeur de la clé de l'enregistrement initial concernant le
client au sein du champ lié à la clé primaire. Ce champ sert donc à
retrouver toute les occurences formant l'historique d'un client. Ce n'est
pas ce que j'aurais appliqué pour obtenir le même résultat mais ca reste
justifiable comme façon de faire. Par contre ca me force à une requête de
mise à jour après mes insertions au transfert vers son système ce qui
ralenti de beaucoup mon processus.
Ce fut aussi ma réaction lorsque j'ai constaté la documentation qui me fut fournise pour procéder au transfert des données de la source vers cette nouvelle db conçue par un consultant externe. Soit de me demander pourquoi duppliquer un champ. Il sagit d'un lien interne à cette table. En fait ce même déccor se retrouve en chacune de ces tables de son système. Selon son explication, ce mécanisme sert à des fins d'historique des données. Disons que l'on parle d'une table de clients, le premier enregistrement concernant un client donné retrouvera la valeur de sa clé duppliqué au sein d'un champ qui est en liaison interne avec la clé de la table. Si une modification à lieu, une nouvelle insertion est faite et le nouvel enregistrement se voit recevoir la valeur de la clé de l'enregistrement initial concernant le client au sein du champ lié à la clé primaire. Ce champ sert donc à retrouver toute les occurences formant l'historique d'un client. Ce n'est pas ce que j'aurais appliqué pour obtenir le même résultat mais ca reste justifiable comme façon de faire. Par contre ca me force à une requête de mise à jour après mes insertions au transfert vers son système ce qui ralenti de beaucoup mon processus.
Jean-François Courteau
bruno reiter [MVP]
Si j'ai compris, ce n'est pas la valeur de l'identity qu'il faut dans cette colonne, mais soit l'identity, soit l'identity du client d'origine. Donc il faut peut-etre mettre un trigger qui récupérera l'identity de l'enreg en cours si la colonne est vide, sachant que cette colonne ne sera pas vide dans le cas où c'est le numéro d'un autre client d'origine.
br
"Jean-Francois Courteau" wrote in message news:#
Ce fut aussi ma réaction lorsque j'ai constaté la documentation qui me fut fournise pour procéder au transfert des données de la source vers cette nouvelle db conçue par un consultant externe. Soit de me demander
pourquoi
duppliquer un champ. Il sagit d'un lien interne à cette table. En fait ce même déccor se retrouve en chacune de ces tables de son système. Selon son explication, ce mécanisme sert à des fins d'historique des données. Disons que l'on parle d'une table de clients, le premier enregistrement
concernant
un client donné retrouvera la valeur de sa clé duppliqué au sein d'un
champ
qui est en liaison interne avec la clé de la table. Si une modification à lieu, une nouvelle insertion est faite et le nouvel enregistrement se voit recevoir la valeur de la clé de l'enregistrement initial concernant le client au sein du champ lié à la clé primaire. Ce champ sert donc à retrouver toute les occurences formant l'historique d'un client. Ce n'est pas ce que j'aurais appliqué pour obtenir le même résultat mais ca reste justifiable comme façon de faire. Par contre ca me force à une requête de mise à jour après mes insertions au transfert vers son système ce qui ralenti de beaucoup mon processus.
Jean-François Courteau
Si j'ai compris, ce n'est pas la valeur de l'identity qu'il faut dans cette
colonne, mais soit l'identity, soit l'identity du client d'origine.
Donc il faut peut-etre mettre un trigger qui récupérera l'identity de
l'enreg en cours si la colonne est vide, sachant que cette colonne ne sera
pas vide dans le cas où c'est le numéro d'un autre client d'origine.
br
"Jean-Francois Courteau" <jfcourteau@boxisp.com> wrote in message
news:#kVzgop5EHA.3644@tk2msftngp13.phx.gbl...
Ce fut aussi ma réaction lorsque j'ai constaté la documentation qui me fut
fournise pour procéder au transfert des données de la source vers cette
nouvelle db conçue par un consultant externe. Soit de me demander
pourquoi
duppliquer un champ. Il sagit d'un lien interne à cette table. En fait ce
même déccor se retrouve en chacune de ces tables de son système. Selon son
explication, ce mécanisme sert à des fins d'historique des données. Disons
que l'on parle d'une table de clients, le premier enregistrement
concernant
un client donné retrouvera la valeur de sa clé duppliqué au sein d'un
champ
qui est en liaison interne avec la clé de la table. Si une modification à
lieu, une nouvelle insertion est faite et le nouvel enregistrement se voit
recevoir la valeur de la clé de l'enregistrement initial concernant le
client au sein du champ lié à la clé primaire. Ce champ sert donc à
retrouver toute les occurences formant l'historique d'un client. Ce n'est
pas ce que j'aurais appliqué pour obtenir le même résultat mais ca reste
justifiable comme façon de faire. Par contre ca me force à une requête de
mise à jour après mes insertions au transfert vers son système ce qui
ralenti de beaucoup mon processus.
Si j'ai compris, ce n'est pas la valeur de l'identity qu'il faut dans cette colonne, mais soit l'identity, soit l'identity du client d'origine. Donc il faut peut-etre mettre un trigger qui récupérera l'identity de l'enreg en cours si la colonne est vide, sachant que cette colonne ne sera pas vide dans le cas où c'est le numéro d'un autre client d'origine.
br
"Jean-Francois Courteau" wrote in message news:#
Ce fut aussi ma réaction lorsque j'ai constaté la documentation qui me fut fournise pour procéder au transfert des données de la source vers cette nouvelle db conçue par un consultant externe. Soit de me demander
pourquoi
duppliquer un champ. Il sagit d'un lien interne à cette table. En fait ce même déccor se retrouve en chacune de ces tables de son système. Selon son explication, ce mécanisme sert à des fins d'historique des données. Disons que l'on parle d'une table de clients, le premier enregistrement
concernant
un client donné retrouvera la valeur de sa clé duppliqué au sein d'un
champ
qui est en liaison interne avec la clé de la table. Si une modification à lieu, une nouvelle insertion est faite et le nouvel enregistrement se voit recevoir la valeur de la clé de l'enregistrement initial concernant le client au sein du champ lié à la clé primaire. Ce champ sert donc à retrouver toute les occurences formant l'historique d'un client. Ce n'est pas ce que j'aurais appliqué pour obtenir le même résultat mais ca reste justifiable comme façon de faire. Par contre ca me force à une requête de mise à jour après mes insertions au transfert vers son système ce qui ralenti de beaucoup mon processus.
Jean-François Courteau
Jean-Francois Courteau
Tout à fait ! C'est exactement ce qu'il doit en être. Je suis à préparer un script de transfert qui emplira ce nouveau dépôt à partir de la db d'un ancien système. Comme dans le cas de mon transfert, les occurences seront considérées comme les premières insertions de chaque entité, la valeur de ce fameux champs doit être égale à celui du champ identity dans tout les cas. Je voudrais donc pouvoir utiliser la valeur générée au sein du champ identity au sein de cet autre champ, directement en ma requête d'insertion.
Je pense avoir la seule solution possible en main actuellement soit :
insert into MaTable(ChampReplicatIdent) values(@@identity + ValeurIncrement)
Les solutions sont souvent cette simplicité qui nous pend au bout du nez lol
Jean-François Courteau
"bruno reiter [MVP]" <remove.this! a écrit dans le message de news:
Si j'ai compris, ce n'est pas la valeur de l'identity qu'il faut dans
cette
colonne, mais soit l'identity, soit l'identity du client d'origine. Donc il faut peut-etre mettre un trigger qui récupérera l'identity de l'enreg en cours si la colonne est vide, sachant que cette colonne ne sera pas vide dans le cas où c'est le numéro d'un autre client d'origine.
br
"Jean-Francois Courteau" wrote in message news:# > Ce fut aussi ma réaction lorsque j'ai constaté la documentation qui me
fut
> fournise pour procéder au transfert des données de la source vers cette > nouvelle db conçue par un consultant externe. Soit de me demander pourquoi > duppliquer un champ. Il sagit d'un lien interne à cette table. En fait
ce
> même déccor se retrouve en chacune de ces tables de son système. Selon
son
> explication, ce mécanisme sert à des fins d'historique des données.
Disons
> que l'on parle d'une table de clients, le premier enregistrement concernant > un client donné retrouvera la valeur de sa clé duppliqué au sein d'un champ > qui est en liaison interne avec la clé de la table. Si une modification
à
> lieu, une nouvelle insertion est faite et le nouvel enregistrement se
voit
> recevoir la valeur de la clé de l'enregistrement initial concernant le > client au sein du champ lié à la clé primaire. Ce champ sert donc à > retrouver toute les occurences formant l'historique d'un client. Ce
n'est
> pas ce que j'aurais appliqué pour obtenir le même résultat mais ca reste > justifiable comme façon de faire. Par contre ca me force à une requête
de
> mise à jour après mes insertions au transfert vers son système ce qui > ralenti de beaucoup mon processus. > > Jean-François Courteau > >
Tout à fait ! C'est exactement ce qu'il doit en être. Je suis à préparer un
script de transfert qui emplira ce nouveau dépôt à partir de la db d'un
ancien système. Comme dans le cas de mon transfert, les occurences seront
considérées comme les premières insertions de chaque entité, la valeur de ce
fameux champs doit être égale à celui du champ identity dans tout les cas.
Je voudrais donc pouvoir utiliser la valeur générée au sein du champ
identity au sein de cet autre champ, directement en ma requête d'insertion.
Je pense avoir la seule solution possible en main actuellement soit :
insert into MaTable(ChampReplicatIdent) values(@@identity + ValeurIncrement)
Les solutions sont souvent cette simplicité qui nous pend au bout du nez lol
Jean-François Courteau
"bruno reiter [MVP]" <remove.this!.br33@bol.com.br> a écrit dans le message
de news:uTZVWaq5EHA.3120@TK2MSFTNGP12.phx.gbl...
Si j'ai compris, ce n'est pas la valeur de l'identity qu'il faut dans
cette
colonne, mais soit l'identity, soit l'identity du client d'origine.
Donc il faut peut-etre mettre un trigger qui récupérera l'identity de
l'enreg en cours si la colonne est vide, sachant que cette colonne ne sera
pas vide dans le cas où c'est le numéro d'un autre client d'origine.
br
"Jean-Francois Courteau" <jfcourteau@boxisp.com> wrote in message
news:#kVzgop5EHA.3644@tk2msftngp13.phx.gbl...
> Ce fut aussi ma réaction lorsque j'ai constaté la documentation qui me
fut
> fournise pour procéder au transfert des données de la source vers cette
> nouvelle db conçue par un consultant externe. Soit de me demander
pourquoi
> duppliquer un champ. Il sagit d'un lien interne à cette table. En fait
ce
> même déccor se retrouve en chacune de ces tables de son système. Selon
son
> explication, ce mécanisme sert à des fins d'historique des données.
Disons
> que l'on parle d'une table de clients, le premier enregistrement
concernant
> un client donné retrouvera la valeur de sa clé duppliqué au sein d'un
champ
> qui est en liaison interne avec la clé de la table. Si une modification
à
> lieu, une nouvelle insertion est faite et le nouvel enregistrement se
voit
> recevoir la valeur de la clé de l'enregistrement initial concernant le
> client au sein du champ lié à la clé primaire. Ce champ sert donc à
> retrouver toute les occurences formant l'historique d'un client. Ce
n'est
> pas ce que j'aurais appliqué pour obtenir le même résultat mais ca reste
> justifiable comme façon de faire. Par contre ca me force à une requête
de
> mise à jour après mes insertions au transfert vers son système ce qui
> ralenti de beaucoup mon processus.
>
> Jean-François Courteau
>
>
Tout à fait ! C'est exactement ce qu'il doit en être. Je suis à préparer un script de transfert qui emplira ce nouveau dépôt à partir de la db d'un ancien système. Comme dans le cas de mon transfert, les occurences seront considérées comme les premières insertions de chaque entité, la valeur de ce fameux champs doit être égale à celui du champ identity dans tout les cas. Je voudrais donc pouvoir utiliser la valeur générée au sein du champ identity au sein de cet autre champ, directement en ma requête d'insertion.
Je pense avoir la seule solution possible en main actuellement soit :
insert into MaTable(ChampReplicatIdent) values(@@identity + ValeurIncrement)
Les solutions sont souvent cette simplicité qui nous pend au bout du nez lol
Jean-François Courteau
"bruno reiter [MVP]" <remove.this! a écrit dans le message de news:
Si j'ai compris, ce n'est pas la valeur de l'identity qu'il faut dans
cette
colonne, mais soit l'identity, soit l'identity du client d'origine. Donc il faut peut-etre mettre un trigger qui récupérera l'identity de l'enreg en cours si la colonne est vide, sachant que cette colonne ne sera pas vide dans le cas où c'est le numéro d'un autre client d'origine.
br
"Jean-Francois Courteau" wrote in message news:# > Ce fut aussi ma réaction lorsque j'ai constaté la documentation qui me
fut
> fournise pour procéder au transfert des données de la source vers cette > nouvelle db conçue par un consultant externe. Soit de me demander pourquoi > duppliquer un champ. Il sagit d'un lien interne à cette table. En fait
ce
> même déccor se retrouve en chacune de ces tables de son système. Selon
son
> explication, ce mécanisme sert à des fins d'historique des données.
Disons
> que l'on parle d'une table de clients, le premier enregistrement concernant > un client donné retrouvera la valeur de sa clé duppliqué au sein d'un champ > qui est en liaison interne avec la clé de la table. Si une modification
à
> lieu, une nouvelle insertion est faite et le nouvel enregistrement se
voit
> recevoir la valeur de la clé de l'enregistrement initial concernant le > client au sein du champ lié à la clé primaire. Ce champ sert donc à > retrouver toute les occurences formant l'historique d'un client. Ce
n'est
> pas ce que j'aurais appliqué pour obtenir le même résultat mais ca reste > justifiable comme façon de faire. Par contre ca me force à une requête
de
> mise à jour après mes insertions au transfert vers son système ce qui > ralenti de beaucoup mon processus. > > Jean-François Courteau > >
Jean-Francois Courteau
Finalement, mon cas n'est pas réglé, le @@identity n'a pas la bonne valeur au moment de son utilisation puisque plusieurs tables sont affectées dans le cadre d'une occurence transférée ce qui fait en sorte que le @@identity contient la dernière insertion dans une autre table que celle dont je désire la valeur du champ identity de la dernière insertion.
Si jamais vous pensiez à quelque chose je vous en serait reconnaissant mais je commence à me résigner à cette solution semi-viable que m'apporte l'utilisation d'un trigger à chaque table.
Jean-François Courteau
Finalement, mon cas n'est pas réglé, le @@identity n'a pas la bonne valeur
au moment de son utilisation puisque plusieurs tables sont affectées dans le
cadre d'une occurence transférée ce qui fait en sorte que le @@identity
contient la dernière insertion dans une autre table que celle dont je désire
la valeur du champ identity de la dernière insertion.
Si jamais vous pensiez à quelque chose je vous en serait reconnaissant mais
je commence à me résigner à cette solution semi-viable que m'apporte
l'utilisation d'un trigger à chaque table.
Finalement, mon cas n'est pas réglé, le @@identity n'a pas la bonne valeur au moment de son utilisation puisque plusieurs tables sont affectées dans le cadre d'une occurence transférée ce qui fait en sorte que le @@identity contient la dernière insertion dans une autre table que celle dont je désire la valeur du champ identity de la dernière insertion.
Si jamais vous pensiez à quelque chose je vous en serait reconnaissant mais je commence à me résigner à cette solution semi-viable que m'apporte l'utilisation d'un trigger à chaque table.
Jean-François Courteau
bruno reiter [MVP]
un trigger sur insert qui met dans la colonne ident2 le contenu de la colonne identity.
br
"Jean-Francois Courteau" wrote in message news:#H2$Y$
Finalement, mon cas n'est pas réglé, le @@identity n'a pas la bonne valeur au moment de son utilisation puisque plusieurs tables sont affectées dans
le
cadre d'une occurence transférée ce qui fait en sorte que le @@identity contient la dernière insertion dans une autre table que celle dont je
désire
la valeur du champ identity de la dernière insertion.
Si jamais vous pensiez à quelque chose je vous en serait reconnaissant
mais
je commence à me résigner à cette solution semi-viable que m'apporte l'utilisation d'un trigger à chaque table.
Jean-François Courteau
un trigger sur insert qui met dans la colonne ident2 le contenu de la
colonne identity.
br
"Jean-Francois Courteau" <jfcourteau@boxisp.com> wrote in message
news:#H2$Y$q5EHA.3708@TK2MSFTNGP14.phx.gbl...
Finalement, mon cas n'est pas réglé, le @@identity n'a pas la bonne valeur
au moment de son utilisation puisque plusieurs tables sont affectées dans
le
cadre d'une occurence transférée ce qui fait en sorte que le @@identity
contient la dernière insertion dans une autre table que celle dont je
désire
la valeur du champ identity de la dernière insertion.
Si jamais vous pensiez à quelque chose je vous en serait reconnaissant
mais
je commence à me résigner à cette solution semi-viable que m'apporte
l'utilisation d'un trigger à chaque table.
un trigger sur insert qui met dans la colonne ident2 le contenu de la colonne identity.
br
"Jean-Francois Courteau" wrote in message news:#H2$Y$
Finalement, mon cas n'est pas réglé, le @@identity n'a pas la bonne valeur au moment de son utilisation puisque plusieurs tables sont affectées dans
le
cadre d'une occurence transférée ce qui fait en sorte que le @@identity contient la dernière insertion dans une autre table que celle dont je
désire
la valeur du champ identity de la dernière insertion.
Si jamais vous pensiez à quelque chose je vous en serait reconnaissant
mais
je commence à me résigner à cette solution semi-viable que m'apporte l'utilisation d'un trigger à chaque table.
Jean-François Courteau
Philippe T [MS]
Bonjour,
Je pense qu'effectivement c'est la meilleur solution (celle de bruno). Du coup, vous n'utilisez pas @@identity mais la table insert au sein du trigger.
Phil. ________________________________________________________ Philippe TROTIN http://blogs.msdn.com/ptrotin Microsoft Services France http://www.microsoft.com/france
"bruno reiter [MVP]" <remove.this! wrote in message news:#
un trigger sur insert qui met dans la colonne ident2 le contenu de la colonne identity.
br
"Jean-Francois Courteau" wrote in message news:#H2$Y$ > Finalement, mon cas n'est pas réglé, le @@identity n'a pas la bonne
valeur
> au moment de son utilisation puisque plusieurs tables sont affectées
dans
le > cadre d'une occurence transférée ce qui fait en sorte que le @@identity > contient la dernière insertion dans une autre table que celle dont je désire > la valeur du champ identity de la dernière insertion. > > Si jamais vous pensiez à quelque chose je vous en serait reconnaissant mais > je commence à me résigner à cette solution semi-viable que m'apporte > l'utilisation d'un trigger à chaque table. > > Jean-François Courteau > >
Bonjour,
Je pense qu'effectivement c'est la meilleur solution (celle de bruno). Du
coup, vous n'utilisez pas @@identity mais la table insert au sein du
trigger.
Phil.
________________________________________________________
Philippe TROTIN http://blogs.msdn.com/ptrotin
Microsoft Services France http://www.microsoft.com/france
"bruno reiter [MVP]" <remove.this!.br33@bol.com.br> wrote in message
news:#fIPOWr5EHA.2804@TK2MSFTNGP15.phx.gbl...
un trigger sur insert qui met dans la colonne ident2 le contenu de la
colonne identity.
br
"Jean-Francois Courteau" <jfcourteau@boxisp.com> wrote in message
news:#H2$Y$q5EHA.3708@TK2MSFTNGP14.phx.gbl...
> Finalement, mon cas n'est pas réglé, le @@identity n'a pas la bonne
valeur
> au moment de son utilisation puisque plusieurs tables sont affectées
dans
le
> cadre d'une occurence transférée ce qui fait en sorte que le @@identity
> contient la dernière insertion dans une autre table que celle dont je
désire
> la valeur du champ identity de la dernière insertion.
>
> Si jamais vous pensiez à quelque chose je vous en serait reconnaissant
mais
> je commence à me résigner à cette solution semi-viable que m'apporte
> l'utilisation d'un trigger à chaque table.
>
> Jean-François Courteau
>
>
Je pense qu'effectivement c'est la meilleur solution (celle de bruno). Du coup, vous n'utilisez pas @@identity mais la table insert au sein du trigger.
Phil. ________________________________________________________ Philippe TROTIN http://blogs.msdn.com/ptrotin Microsoft Services France http://www.microsoft.com/france
"bruno reiter [MVP]" <remove.this! wrote in message news:#
un trigger sur insert qui met dans la colonne ident2 le contenu de la colonne identity.
br
"Jean-Francois Courteau" wrote in message news:#H2$Y$ > Finalement, mon cas n'est pas réglé, le @@identity n'a pas la bonne
valeur
> au moment de son utilisation puisque plusieurs tables sont affectées
dans
le > cadre d'une occurence transférée ce qui fait en sorte que le @@identity > contient la dernière insertion dans une autre table que celle dont je désire > la valeur du champ identity de la dernière insertion. > > Si jamais vous pensiez à quelque chose je vous en serait reconnaissant mais > je commence à me résigner à cette solution semi-viable que m'apporte > l'utilisation d'un trigger à chaque table. > > Jean-François Courteau > >
