Depuis SET IDENTITY_INSERT
est sensible à la session, il est géré au niveau du tampon sans être stocké quelque part. Cela signifie que nous n'avons pas besoin de vérifier le IDENTITY_INSERT
car nous n'utilisons jamais ce mot clé dans la session actuelle.
Désolé, je ne peux pas vous aider.
Bonne question cependant :)
Fuente: Ici
Mise à jour Il existe peut-être des moyens de le faire, comme le montre le site que j'ai mis en lien, mais, selon moi, cela demande trop d'efforts pour être utile.
if
(select max(id) from MyTable) < (select max(id) from inserted)
--Then you may be inserting a record normally
BEGIN
set @I = 1 --SQL wants something to happen in the "IF" side of an IF/ELSE
END
ELSE --You definitely have IDENTITY_INSERT on. Done as ELSE instead of the other way around so that if there is no inserted table, it will run anyway
BEGIN
.... Code that shouldn't run with IDENTITY_INSERT on
END
5 votes
Il est amusant de constater que vous avez mentionné que les gens comprennent mal la question et que la grande majorité des réponses ici font exactement cela.
4 votes
Pour vous et les autres personnes qui se renseignent sur le sujet, la vraie question est la suivante : sessions . Vous ne voudrez probablement vérifier/restaurer la valeur d'IDENTITY_INSERT que pour un fichier de type session suffisamment long et compliqué pour permettre, puis empêcher, les insertions d'identité. (Une étape de travail en continu ?) PARCE QUE si vous démarrez une nouvelle session,
IDENTITY_INSERT
est éteint ! Si vous n'êtes pas sûr que quelque chose reste la même session, sessions google (pas exactement = connexions), consultezsys.dm_exec_sessions
ysys.dm_exec_connections
ou téléchargersp_WhoIsActive
yEXEC sp_WhoIsActive @show_sleeping_spids = 2, @show_own_spid = 1