pour un étudiant, je dois insérer dans la base tous ces jours de présences
(dans une table 'PRESENCES')
puis en même temps inserer le details des activitées réalisées lors de cette
journée (dans 'DETAILS_PRESENCES')
mon problème est que la table 'DETAILS_PRESENCES' contient une clé étrangère
qui fait référence à une colonne autoincrement de la table 'PRESENCES'
Seulement, au moment de créer ma requete, je ne connais pas la valeur
qu'aura cette colonne et donc je ne peux pas renseigner cette valeur dans ma
sous table 'DETAILS_PRESENCES'
Je me suis peut être mal exprimé mais c'est bien ce que voulait dire mon post. J'utilise, pour ma part, scope_identity() afin de me prémunir d'une instruction qui serait contenue dans un trigger ... et garantir de ce fait de bien récupérer la valeur de l'identité générée lors de mon Insert. Prévoyons l'avenir et donc les évolutions des modèles de données et instructions qui pourraient y être ajoutées. ;)
-- arno - http://www.dotnetguru2.org/acleret/
"Fred BROUARD" a écrit :
Arnaud CLERET a écrit : > Bonsoir, > > Préférez l'utilisation de scope_identity() plutot que @@Identity afin d'être > sur de récupérer la dernière valeur générée dans le scope actuel et non de > manière globale. >
Ce que vous dites est faux !
@@IDENTITY est propre à la session donc il n'y a pas de problème, c'est la dernière insertion d'autoincrément dans la session et quelque soit la table. SCOPE_IDENTITY est plus gourmand en terme de ressources et sa visibilité est limité au module (proc stock, trigger, fonction ou lot) et toujours dans la session.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Bonjour,
Je me suis peut être mal exprimé mais c'est bien ce que voulait dire mon
post. J'utilise, pour ma part, scope_identity() afin de me prémunir d'une
instruction qui serait contenue dans un trigger ... et garantir de ce fait de
bien récupérer la valeur de l'identité générée lors de mon Insert. Prévoyons
l'avenir et donc les évolutions des modèles de données et instructions qui
pourraient y être ajoutées. ;)
--
arno - http://www.dotnetguru2.org/acleret/
"Fred BROUARD" a écrit :
Arnaud CLERET a écrit :
> Bonsoir,
>
> Préférez l'utilisation de scope_identity() plutot que @@Identity afin d'être
> sur de récupérer la dernière valeur générée dans le scope actuel et non de
> manière globale.
>
Ce que vous dites est faux !
@@IDENTITY est propre à la session donc il n'y a pas de problème, c'est
la dernière insertion d'autoincrément dans la session et quelque soit la
table.
SCOPE_IDENTITY est plus gourmand en terme de ressources et sa visibilité
est limité au module (proc stock, trigger, fonction ou lot) et toujours
dans la session.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Je me suis peut être mal exprimé mais c'est bien ce que voulait dire mon post. J'utilise, pour ma part, scope_identity() afin de me prémunir d'une instruction qui serait contenue dans un trigger ... et garantir de ce fait de bien récupérer la valeur de l'identité générée lors de mon Insert. Prévoyons l'avenir et donc les évolutions des modèles de données et instructions qui pourraient y être ajoutées. ;)
-- arno - http://www.dotnetguru2.org/acleret/
"Fred BROUARD" a écrit :
Arnaud CLERET a écrit : > Bonsoir, > > Préférez l'utilisation de scope_identity() plutot que @@Identity afin d'être > sur de récupérer la dernière valeur générée dans le scope actuel et non de > manière globale. >
Ce que vous dites est faux !
@@IDENTITY est propre à la session donc il n'y a pas de problème, c'est la dernière insertion d'autoincrément dans la session et quelque soit la table. SCOPE_IDENTITY est plus gourmand en terme de ressources et sa visibilité est limité au module (proc stock, trigger, fonction ou lot) et toujours dans la session.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
