Discussion :

[Piou2fois]

Bonjour
J'ai 2 tables

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
T_MACHINE_MCH
 MCH_ID
 MCH_NUM
 ...
T_PIECES_PIE
 PIE_ID
 MCH_ID
 PIE_QTE
 PIE_DESCRIPTION
 PIE_MARQUE
 PIE_REMARQUE

La table T_PIECES_PIE est en fait liée à la première par MCH_ID et correspond à la liste des pièces contenue dans une machine
J'aimerai en fait pouvoir dupliquer un enregistrement de la table T_MACHINE_MCH et que le nouvel enregistrement ait déjà les éléments de la table T_PIECES_PIE (avec bien sur MCH_ID du nouvel enregistrement de la table T_MACHINE_MCH)
Dois-je passer par une procédure ? et si oui comment récupérer le ID de l'enregistrement nouvellement créé ?
D'avance merci
Guillaume

[aieeeuuuuu]

Bonjour,

Si j'ai bien compris votre demande (ce dont je ne suis pas bien sûr ! ), vous voulez insérer dans deux tables différentes, donc vous devez faire deux ordres INSERT distinct.

1/ Commencez par inserer la nouvelle machine,
2/ récupérez l'identifiant de la nouvelle machine créée,
3/ puis insérez dans la table des pièces, en faisant un SELECT sur cette même table pour récupérer les lignes de votre machine de référence

Englobez tout ça dans une transaction.
Vous pouvez effectivement mettre tout ça dans une procédure stockée, en raison de la nécessité de la transaction, c'est mieux !

[Piou2fois]

C'est en effet ce que je veux faire
Pour faire simple : j'ai des machines, chaque machine a des éléments. Je veux faire une copie d'une machine qui embarque ses éléments.
Comment récupérer le ID généré par un INSERT dans une transaction ?

[aieeeuuuuu]

Si vous n'ajoutez qu'une ligne, vous pouvez utiliser SCOPE_IDENTITY

[Piou2fois]

Super merci, je vais regarder pour faire ma procédure avec comme paramètre le ID de la machine que je veux dupliquer, et faire une transaction.
Je viendrais mettre le résultat ici

[Lyche]

heu... une clause OUTPUT sur le premier insert devrait permettre de gérer le soucis non?

Code sql :

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

1
2
3
4
5
INSERT INTO dbo.maTable1( Champ1, Champ2 )
OUTPUT INSERTED.id_auto_increment, INSERTED.Champ1, INSERTED.champ2
  INTO dbo.maTable2( id, Champ1, Champ2 )
SELECT champ1, champ2
  FROM dbo.maTable;

Cette clause permet de travailler avec les tables inserted et deleted directement lors d'un insert (utilisable aussi sur du MERGE de façon très avancée).

Tu pourrais t'inspirer de ça pour faire un code plus court.

Cordialement,
Lyche

[Piou2fois]

Je vais jeter un oeil à ça aussi, sauf si je me trompe, avec ton code je peux pousser plus loin et insérer plusieurs enregistrement de ma première table (avec la clause WHERE par exemple), ça va automatiquement embarquer les enregistrements de ma table 2
Je vais faire un jeu de test et valider l'idée.
Merci pour cette clause OUTPUT

[Lyche]

Je vais jeter un oeil à ça aussi, sauf si je me trompe, avec ton code je peux pousser plus loin et insérer plusieurs enregistrement de ma première table (avec la clause WHERE par exemple), ça va automatiquement embarquer les enregistrements de ma table 2
Je vais faire un jeu de test et valider l'idée.
Merci pour cette clause OUTPUT

Exact, c'est une clause ensembliste. Elle te permettra d'éviter les curseurs et les trigger (dangereux si mal maitrisés) dans des cas de gestion d'historique.

Cordialement,
Lyche

[Piou2fois]

Justement j'utilise les TRIGGERS pour gérer mon historique de modification (les données modifiées ou supprimer sont sauvegarder dans un table similaire avec un champ ID en plus et un champ DATEMODIF et USERMODIF pour suivre.

[Lyche]

Justement j'utilise les TRIGGERS pour gérer mon historique de modification (les données modifiées ou supprimer sont sauvegarder dans un table similaire avec un champ ID en plus et un champ DATEMODIF et USERMODIF pour suivre.

Et bien avec la clause output tu pourrais les gérer directement.

Code sql :

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

1
2
3
4
5
6
 
INSERT...
OUTPUT INSERTED.*, GETDATE(), User_id()
INTO maTableHisto
SELECT *
  FROM ...

[Piou2fois]

Oui sauf que mes modifications sont gérées par Access (projet ADP) et que donc je n'ai pas accès aux requêtes de modifications ou ajout directement

C'est seulement pour des duplications de données où je veux créer des boutons spécifiques avec derrière du code.
La question que je me pose c'est vaut-il mieux créer une procédure et appeler la procédure (et donc garder le code du côté serveur) ou travailler directement avec du code SQL dans le code VBA côté client. Mais bon ça c'est une autre histoire...

[aieeeuuuuu]

heu... une clause OUTPUT sur le premier insert devrait permettre de gérer le soucis non?

A priori non, si la base est bien conçue, car la cible de la clause OUTPUT INTO ne peut être liée à une contrainte d'intégrité référentielle.

Or, ici, T_PIECES_PIE référence T_MACHINE_MCH


Cela dit, dans le cas ou la procédure devrait gérer l'ajout de plusieurs machines en même temps, elle pourrait être utile pour récupérer dans une table temporaire les ID générés

[Lyche]

Oui sauf que mes modifications sont gérées par Access (projet ADP) et que donc je n'ai pas accès aux requêtes de modifications ou ajout directement

C'est seulement pour des duplications de données où je veux créer des boutons spécifiques avec derrière du code.
La question que je me pose c'est vaut-il mieux créer une procédure et appeler la procédure (et donc garder le code du côté serveur) ou travailler directement avec du code SQL dans le code VBA côté client. Mais bon ça c'est une autre histoire...

Personnellement, je trouve que travailler le SQL dans le VBA c'est pas la bonne idée.

Il y a pleins de raisons d'ailleurs

1. Meilleure sécuritédu processus
2. une meilleure gestion de l'organisation des processus (tout est au même endroit plutôt que perdu dans des pages de code)
3. Un meilleur suivi en cas de problème etc..

Enfin, c'est un avis personnel. De plus, les procédures te permettent d'exploiter les fonctionnalités avancées de SQL Server. Comme la clause OUTPUT cité plus haut.

[Lyche]

A priori non, si la base est bien conçue, car la cible de la clause OUTPUT INTO ne peut être liée à une contrainte d'intégrité référentielle.

Or, ici, T_PIECES_PIE référence T_MACHINE_MCH


Cela dit, dans le cas ou la procédure devrait gérer l'ajout de plusieurs machines en même temps, elle pourrait être utile pour récupérer dans une table temporaire les ID générés

Ha? je n'ai jamais eu le soucis pourtant j'ai géré des tables avec contraintes via cette clause.
C'est étrange

Au pire on peut Disable la contrainte temporairement non. Si les données sont en provenance d'une table et qu'elles sont déjà géré par intégrité référentielles. On est certain qu'il n'y aura pas d'erreur.

Code sql :

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

1
2
3
4
5
6
7
8
 
ALTER TABLE dbo.maTable ALTER CONSTRAINT maFK_Contraint DISABLED;
 
INSERT...
OUTPUT..
SELECT...
 
ALTER TABLE dbo.maTable ALTER CONSTRAINT maFK_Constraint ENABLED;

Après, le soucis est résolu, peut-être que je me prends la tête pour rien aussi ^_^

[Piou2fois]

Sujet résolu oui, mais rien n'empêche le débat
Moi ça me plait, j'apprends grace à vous

[aieeeuuuuu]

Au pire on peut Disable la contrainte temporairement non. Si les données sont en provenance d'une table et qu'elles sont déjà géré par intégrité référentielles. On est certain qu'il n'y aura pas d'erreur.

Justement, pendant la durée de l'opération, les tables ne sont plus gérées par l'IR, et rien n’empêche pendant ce temps une autre transaction de supprimer des lignes dans la table référencée, ou d'ajouter des lignes orphelines...

[Lyche]

Justement, pendant la durée de l'opération, les tables ne sont plus gérées par l'IR, et rien n’empêche pendant ce temps une autre transaction de supprimer des lignes dans la table référencée, ou d'ajouter des lignes orphelines...

ça c'est certain, mais on peut pas désactiver la contrainte pendant la transaction? (question bête hein, j'ai jamais testé)

De plus, je pense que les entrées de tables doivent êtres surveillées, est-ce qu'il ya d'autres moyens d'insérer dans cette table ou est-ce qu'elle n'est renseignée que par la procédure que nous traitons?

[Piou2fois]

Voici le code que j'ai généré:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
DECLARE @ID_RECUP AS int;
--SELECT * FROM test.T_MACHINE_MCH
--SELECT * FROM test.T_PIECES_PIE
BEGIN TRANSACTION
INSERT INTO test.T_MACHINE_MCH(MCH_NUM)
SELECT MCH_NUM FROM test.T_MACHINE_MCH WHERE MCH_ID=1;
SET @ID_RECUP = (SELECT SCOPE_IDENTITY());
INSERT INTO test.T_PIECES_PIE(MCH_ID,PIE_QTE,PIE_DESCRIPTION)
SELECT @ID_RECUP,PIE_QTE,PIE_DESCRIPTION FROM test.T_PIECES_PIE WHERE MCH_ID=1;
COMMIT TRANSACTION
--SELECT * FROM test.T_MACHINE_MCH
--SELECT * FROM test.T_PIECES_PIE

"test" est mon schéma :o)
Je vais transcrire ça dans une procédure avec un paramètre équivalent à "1" qui est en fait l'ID de la machine que je veux dupliquer.
Si vous voyez des erreurs, merci d'avance !