Je possède 3 tables pour une relation "many to many".
Appelons les 3 tables : A, B & C avec les champs de relations (voir flèche).
+---+ +---+ +---+
| A |--->| B |<---| C |
+---+ +---+ +---+
Du fait que je dois faire un historique (l'utilisateur doit pouvoir voir les
valeurs précédantes).
A l'enregistrement, je dois donc dupliquer les données (dans les 3 tables) et je
modifie le contenu du nouveau.
Dupliquer dans les tables 'A' et 'C' est très simple:
INSERT INTO "A" INSERT INTO "C"
SELECT FROM A SELECT FROM C
WHERE condition WHERE condition
Dupliquer B est le même
INSERT INTO "B"
SELECT FROM B
WHERE condition
Mon problème est la mise à jour des liens de la table "B" qui fait le lien entre
la table "A" & "B" et les liens entre la table "B" & "C". Comment faire?
Surtout sur que je peut avoir un ou plusieurs enregistrements de chaque coté!
Cela fait une semaine que je m'arrache les cheveux la dessus !
Maintenant j'appelle au-secours
Pourqoui ne pas enregister l'historique dans des tables annexes ?
Bonjour, ici, je vous montre un principe, car en réalité la structure est beaucoup plus complexe. Cela évite d'ajouter des dizaines de tables.
André
bruno reiter
les colonnes en relation entre A et B, C et B sont de quel type (autoincréments ou valeus données?)
Je ne comprend pas ce que vient faire la notion d'historique et duplication.
Avec le peu que j'ai compris, je pense qu'il faut stocker en temporaire les valeurs de clé insérées dans A, puis dans C pour pouvoir reconstruire B
br
<Andre.L' wrote in message news:
Bonjour,
Je suis complètement perdu. J'explique.
Je possède 3 tables pour une relation "many to many". Appelons les 3 tables : A, B & C avec les champs de relations (voir flèche).
+---+ +---+ +---+ | A |--->| B |<---| C | +---+ +---+ +---+
Du fait que je dois faire un historique (l'utilisateur doit pouvoir voir les valeurs précédantes).
A l'enregistrement, je dois donc dupliquer les données (dans les 3 tables) et je modifie le contenu du nouveau.
Dupliquer dans les tables 'A' et 'C' est très simple:
INSERT INTO "A" INSERT INTO "C" SELECT FROM A SELECT FROM C WHERE condition WHERE condition
Dupliquer B est le même INSERT INTO "B" SELECT FROM B WHERE condition
Mon problème est la mise à jour des liens de la table "B" qui fait le lien entre la table "A" & "B" et les liens entre la table "B" & "C". Comment faire?
Surtout sur que je peut avoir un ou plusieurs enregistrements de chaque coté!
Cela fait une semaine que je m'arrache les cheveux la dessus ! Maintenant j'appelle au-secours
Merci d'avance au bonne âme qui m'aideront !
André
les colonnes en relation entre A et B, C et B sont de quel type
(autoincréments ou valeus données?)
Je ne comprend pas ce que vient faire la notion d'historique et duplication.
Avec le peu que j'ai compris, je pense qu'il faut stocker en temporaire les
valeurs de clé insérées dans A, puis dans C pour pouvoir reconstruire B
br
<Andre.L'HOIR@ext.ec.europa.eu> wrote in message
news:f9ep89012vq@drn.newsguy.com...
Bonjour,
Je suis complètement perdu. J'explique.
Je possède 3 tables pour une relation "many to many".
Appelons les 3 tables : A, B & C avec les champs de relations (voir
flèche).
+---+ +---+ +---+
| A |--->| B |<---| C |
+---+ +---+ +---+
Du fait que je dois faire un historique (l'utilisateur doit pouvoir voir
les
valeurs précédantes).
A l'enregistrement, je dois donc dupliquer les données (dans les 3 tables)
et je
modifie le contenu du nouveau.
Dupliquer dans les tables 'A' et 'C' est très simple:
INSERT INTO "A" INSERT INTO "C"
SELECT FROM A SELECT FROM C
WHERE condition WHERE condition
Dupliquer B est le même
INSERT INTO "B"
SELECT FROM B
WHERE condition
Mon problème est la mise à jour des liens de la table "B" qui fait le lien
entre
la table "A" & "B" et les liens entre la table "B" & "C". Comment faire?
Surtout sur que je peut avoir un ou plusieurs enregistrements de chaque
coté!
Cela fait une semaine que je m'arrache les cheveux la dessus !
Maintenant j'appelle au-secours
les colonnes en relation entre A et B, C et B sont de quel type (autoincréments ou valeus données?)
Je ne comprend pas ce que vient faire la notion d'historique et duplication.
Avec le peu que j'ai compris, je pense qu'il faut stocker en temporaire les valeurs de clé insérées dans A, puis dans C pour pouvoir reconstruire B
br
<Andre.L' wrote in message news:
Bonjour,
Je suis complètement perdu. J'explique.
Je possède 3 tables pour une relation "many to many". Appelons les 3 tables : A, B & C avec les champs de relations (voir flèche).
+---+ +---+ +---+ | A |--->| B |<---| C | +---+ +---+ +---+
Du fait que je dois faire un historique (l'utilisateur doit pouvoir voir les valeurs précédantes).
A l'enregistrement, je dois donc dupliquer les données (dans les 3 tables) et je modifie le contenu du nouveau.
Dupliquer dans les tables 'A' et 'C' est très simple:
INSERT INTO "A" INSERT INTO "C" SELECT FROM A SELECT FROM C WHERE condition WHERE condition
Dupliquer B est le même INSERT INTO "B" SELECT FROM B WHERE condition
Mon problème est la mise à jour des liens de la table "B" qui fait le lien entre la table "A" & "B" et les liens entre la table "B" & "C". Comment faire?
Surtout sur que je peut avoir un ou plusieurs enregistrements de chaque coté!
Cela fait une semaine que je m'arrache les cheveux la dessus ! Maintenant j'appelle au-secours
Merci d'avance au bonne âme qui m'aideront !
André
Fred.M.
Bonjour André, Je suis assez d'accord avec André dans l'optique d'avoir des tables d'historisation.. Si tel n'est pas possible, tu peux en revanche repenser tes relations entre tes tables en implémentant un champ de type UniqueIdentifer. Tu pourras ainsi distinguer le versionning de tes enregistrements.
Fred.M.
"Andre.L'" a écrit :
In article , =?Utf-8?B?Um9iZXJ0?= says... > >Pourqoui ne pas enregister l'historique dans des tables annexes ?
Bonjour, ici, je vous montre un principe, car en réalité la structure est beaucoup plus complexe. Cela évite d'ajouter des dizaines de tables.
André
Bonjour André,
Je suis assez d'accord avec André dans l'optique d'avoir des tables
d'historisation..
Si tel n'est pas possible, tu peux en revanche repenser tes relations entre
tes tables en implémentant un champ de type UniqueIdentifer. Tu pourras ainsi
distinguer le versionning de tes enregistrements.
Fred.M.
"Andre.L'HOIR@ext.ec.europa.eu" a écrit :
In article <54651FC4-1150-4AC1-B678-375D874E4535@microsoft.com>,
=?Utf-8?B?Um9iZXJ0?= says...
>
>Pourqoui ne pas enregister l'historique dans des tables annexes ?
Bonjour,
ici, je vous montre un principe, car en réalité la structure est beaucoup plus
complexe. Cela évite d'ajouter des dizaines de tables.
Bonjour André, Je suis assez d'accord avec André dans l'optique d'avoir des tables d'historisation.. Si tel n'est pas possible, tu peux en revanche repenser tes relations entre tes tables en implémentant un champ de type UniqueIdentifer. Tu pourras ainsi distinguer le versionning de tes enregistrements.
Fred.M.
"Andre.L'" a écrit :
In article , =?Utf-8?B?Um9iZXJ0?= says... > >Pourqoui ne pas enregister l'historique dans des tables annexes ?
Bonjour, ici, je vous montre un principe, car en réalité la structure est beaucoup plus complexe. Cela évite d'ajouter des dizaines de tables.
André
Andre.L'HOIR
bonjour à tous,
Merci à vous deux pour votre support.
1° - pour répondre à Mr Bruno Reiter:
j'utilise des séquences pour les clefs primaires. Pour l'historisation; Je suis occupé à crée un site internet qui gère toutes la documentation de la législation Européenne. Un truc de fou !... Mais je dois pouvoir faire l'historique de tous cela (en tenant compte des avis des différents de chaque état membre).
2° - pour répondre à Mr Fred M.:
J'utilise éffectivement des champs de Versionning (c'est même un paramètre que je passe à ma fonction) et également des champs 'status' qui me permet de connaitre si l'enregistrement est le dernier publié ou non.
3° - La situation actuelle:
Je suis parvenu à écrire une fonction sous oracle qui dédouble les enregistrements. Lorsque je la fait fonctionner depuis le procédure editor de TOAD, tous va bien.
select duplique(2650, 16, 'dede') as reponse from dual;
ou 2650 est le n° id de l'objet à dupliquer 16 est le nouveau n° de version à appliquer 'dede' est la personne qui fait se changement
Par contre, lorsque je veux l'exécuter depuis le SQL editor, j'ai le message d'erreur suivant:
"ORA-14551 cannot perform a DML operation inside a query"
"DML" ??? qu'est ce que c'est ??
Merci encore André
les colonnes en relation entre A et B, C et B sont de quel type (autoincréments ou valeus données?)
Je ne comprend pas ce que vient faire la notion d'historique et duplication.
Avec le peu que j'ai compris, je pense qu'il faut stocker en temporaire les valeurs de clé insérées dans A, puis dans C pour pouvoir reconstruire B
br
bonjour à tous,
Merci à vous deux pour votre support.
1° - pour répondre à Mr Bruno Reiter:
j'utilise des séquences pour les clefs primaires. Pour l'historisation;
Je suis occupé à crée un site internet qui gère toutes la documentation de la
législation Européenne. Un truc de fou !...
Mais je dois pouvoir faire l'historique de tous cela (en tenant compte des avis
des différents de chaque état membre).
2° - pour répondre à Mr Fred M.:
J'utilise éffectivement des champs de Versionning (c'est même un paramètre que
je passe à ma fonction) et également des champs 'status' qui me permet de
connaitre si l'enregistrement est le dernier publié ou non.
3° - La situation actuelle:
Je suis parvenu à écrire une fonction sous oracle qui dédouble les
enregistrements. Lorsque je la fait fonctionner depuis le procédure editor de
TOAD, tous va bien.
select duplique(2650, 16, 'dede') as reponse from dual;
ou 2650 est le n° id de l'objet à dupliquer
16 est le nouveau n° de version à appliquer
'dede' est la personne qui fait se changement
Par contre, lorsque je veux l'exécuter depuis le SQL editor,
j'ai le message d'erreur suivant:
"ORA-14551 cannot perform a DML operation inside a query"
"DML" ??? qu'est ce que c'est ??
Merci encore
André
les colonnes en relation entre A et B, C et B sont de quel type
(autoincréments ou valeus données?)
Je ne comprend pas ce que vient faire la notion d'historique et duplication.
Avec le peu que j'ai compris, je pense qu'il faut stocker en temporaire les
valeurs de clé insérées dans A, puis dans C pour pouvoir reconstruire B
j'utilise des séquences pour les clefs primaires. Pour l'historisation; Je suis occupé à crée un site internet qui gère toutes la documentation de la législation Européenne. Un truc de fou !... Mais je dois pouvoir faire l'historique de tous cela (en tenant compte des avis des différents de chaque état membre).
2° - pour répondre à Mr Fred M.:
J'utilise éffectivement des champs de Versionning (c'est même un paramètre que je passe à ma fonction) et également des champs 'status' qui me permet de connaitre si l'enregistrement est le dernier publié ou non.
3° - La situation actuelle:
Je suis parvenu à écrire une fonction sous oracle qui dédouble les enregistrements. Lorsque je la fait fonctionner depuis le procédure editor de TOAD, tous va bien.
select duplique(2650, 16, 'dede') as reponse from dual;
ou 2650 est le n° id de l'objet à dupliquer 16 est le nouveau n° de version à appliquer 'dede' est la personne qui fait se changement
Par contre, lorsque je veux l'exécuter depuis le SQL editor, j'ai le message d'erreur suivant:
"ORA-14551 cannot perform a DML operation inside a query"
"DML" ??? qu'est ce que c'est ??
Merci encore André
les colonnes en relation entre A et B, C et B sont de quel type (autoincréments ou valeus données?)
Je ne comprend pas ce que vient faire la notion d'historique et duplication.
Avec le peu que j'ai compris, je pense qu'il faut stocker en temporaire les valeurs de clé insérées dans A, puis dans C pour pouvoir reconstruire B
br
Fred.M.
Bonjour Robert, Argh, en effet tu as bien fait de préciser le contexte car la problématique n'est pas du tout la même. Pour commencer le DML c'est le "Data Manipulation Language", càd le langage de manipulation de données SQL constituées des instructions "Select / Insert / Update / Delete". Ta problématique se cible plutôt sur la cohabitation Oracle / SQL Server. Notamment ".. from dual" est une syntaxe propre à Oracle inexistante sous SQL Server. Toutefois il convient de cerner d'autres points pour mieux comprendre ce que tu veux faire : ? Quelle version d'Oracle ? ? Tu l'attaques par un serveur lié ou autre ? ? SQL server n'est que Client ou il héberge également des données ?
Fred.M
"Andre.L'" a écrit :
bonjour à tous,
Merci à vous deux pour votre support.
1° - pour répondre à Mr Bruno Reiter:
j'utilise des séquences pour les clefs primaires. Pour l'historisation; Je suis occupé à crée un site internet qui gère toutes la documentation de la législation Européenne. Un truc de fou !... Mais je dois pouvoir faire l'historique de tous cela (en tenant compte des avis des différents de chaque état membre).
2° - pour répondre à Mr Fred M.:
J'utilise éffectivement des champs de Versionning (c'est même un paramètre que je passe à ma fonction) et également des champs 'status' qui me permet de connaitre si l'enregistrement est le dernier publié ou non.
3° - La situation actuelle:
Je suis parvenu à écrire une fonction sous oracle qui dédouble les enregistrements. Lorsque je la fait fonctionner depuis le procédure editor de TOAD, tous va bien.
select duplique(2650, 16, 'dede') as reponse from dual;
ou 2650 est le n° id de l'objet à dupliquer 16 est le nouveau n° de version à appliquer 'dede' est la personne qui fait se changement
Par contre, lorsque je veux l'exécuter depuis le SQL editor, j'ai le message d'erreur suivant:
"ORA-14551 cannot perform a DML operation inside a query"
"DML" ??? qu'est ce que c'est ??
Merci encore André
>les colonnes en relation entre A et B, C et B sont de quel type >(autoincréments ou valeus données?) > >Je ne comprend pas ce que vient faire la notion d'historique et duplication. > >Avec le peu que j'ai compris, je pense qu'il faut stocker en temporaire les >valeurs de clé insérées dans A, puis dans C pour pouvoir reconstruire B > >br > >
Bonjour Robert,
Argh, en effet tu as bien fait de préciser le contexte car la problématique
n'est pas du tout la même.
Pour commencer le DML c'est le "Data Manipulation Language", càd le langage
de manipulation de données SQL constituées des instructions "Select / Insert
/ Update / Delete".
Ta problématique se cible plutôt sur la cohabitation Oracle / SQL Server.
Notamment ".. from dual" est une syntaxe propre à Oracle inexistante sous SQL
Server. Toutefois il convient de cerner d'autres points pour mieux comprendre
ce que tu veux faire :
? Quelle version d'Oracle ?
? Tu l'attaques par un serveur lié ou autre ?
? SQL server n'est que Client ou il héberge également des données ?
Fred.M
"Andre.L'HOIR@ext.ec.europa.eu" a écrit :
bonjour à tous,
Merci à vous deux pour votre support.
1° - pour répondre à Mr Bruno Reiter:
j'utilise des séquences pour les clefs primaires. Pour l'historisation;
Je suis occupé à crée un site internet qui gère toutes la documentation de la
législation Européenne. Un truc de fou !...
Mais je dois pouvoir faire l'historique de tous cela (en tenant compte des avis
des différents de chaque état membre).
2° - pour répondre à Mr Fred M.:
J'utilise éffectivement des champs de Versionning (c'est même un paramètre que
je passe à ma fonction) et également des champs 'status' qui me permet de
connaitre si l'enregistrement est le dernier publié ou non.
3° - La situation actuelle:
Je suis parvenu à écrire une fonction sous oracle qui dédouble les
enregistrements. Lorsque je la fait fonctionner depuis le procédure editor de
TOAD, tous va bien.
select duplique(2650, 16, 'dede') as reponse from dual;
ou 2650 est le n° id de l'objet à dupliquer
16 est le nouveau n° de version à appliquer
'dede' est la personne qui fait se changement
Par contre, lorsque je veux l'exécuter depuis le SQL editor,
j'ai le message d'erreur suivant:
"ORA-14551 cannot perform a DML operation inside a query"
"DML" ??? qu'est ce que c'est ??
Merci encore
André
>les colonnes en relation entre A et B, C et B sont de quel type
>(autoincréments ou valeus données?)
>
>Je ne comprend pas ce que vient faire la notion d'historique et duplication.
>
>Avec le peu que j'ai compris, je pense qu'il faut stocker en temporaire les
>valeurs de clé insérées dans A, puis dans C pour pouvoir reconstruire B
>
>br
>
>
Bonjour Robert, Argh, en effet tu as bien fait de préciser le contexte car la problématique n'est pas du tout la même. Pour commencer le DML c'est le "Data Manipulation Language", càd le langage de manipulation de données SQL constituées des instructions "Select / Insert / Update / Delete". Ta problématique se cible plutôt sur la cohabitation Oracle / SQL Server. Notamment ".. from dual" est une syntaxe propre à Oracle inexistante sous SQL Server. Toutefois il convient de cerner d'autres points pour mieux comprendre ce que tu veux faire : ? Quelle version d'Oracle ? ? Tu l'attaques par un serveur lié ou autre ? ? SQL server n'est que Client ou il héberge également des données ?
Fred.M
"Andre.L'" a écrit :
bonjour à tous,
Merci à vous deux pour votre support.
1° - pour répondre à Mr Bruno Reiter:
j'utilise des séquences pour les clefs primaires. Pour l'historisation; Je suis occupé à crée un site internet qui gère toutes la documentation de la législation Européenne. Un truc de fou !... Mais je dois pouvoir faire l'historique de tous cela (en tenant compte des avis des différents de chaque état membre).
2° - pour répondre à Mr Fred M.:
J'utilise éffectivement des champs de Versionning (c'est même un paramètre que je passe à ma fonction) et également des champs 'status' qui me permet de connaitre si l'enregistrement est le dernier publié ou non.
3° - La situation actuelle:
Je suis parvenu à écrire une fonction sous oracle qui dédouble les enregistrements. Lorsque je la fait fonctionner depuis le procédure editor de TOAD, tous va bien.
select duplique(2650, 16, 'dede') as reponse from dual;
ou 2650 est le n° id de l'objet à dupliquer 16 est le nouveau n° de version à appliquer 'dede' est la personne qui fait se changement
Par contre, lorsque je veux l'exécuter depuis le SQL editor, j'ai le message d'erreur suivant:
"ORA-14551 cannot perform a DML operation inside a query"
"DML" ??? qu'est ce que c'est ??
Merci encore André
>les colonnes en relation entre A et B, C et B sont de quel type >(autoincréments ou valeus données?) > >Je ne comprend pas ce que vient faire la notion d'historique et duplication. > >Avec le peu que j'ai compris, je pense qu'il faut stocker en temporaire les >valeurs de clé insérées dans A, puis dans C pour pouvoir reconstruire B > >br > >
