OVH Cloud OVH Cloud

SET IDENTITY INSERT

6 réponses
Avatar
DORAK
Bonjour,

Quand j'envoie ces commandes depuis l'analyseur de requêtes sous SQL Server
2000:

SET IDENTITY_INSERT T1 OFF
go
SET IDENTITY_INSERT T2 ON
go
INSERT INTO T2(C1, C2) VALUES(1,2)
go

J'ai bien une ligne ajoutée dans ma table T2

Ma table T2 est liée dans une base access.

Dans ma base access sur currentproject.connection.execute j'envoie la
requête suivant:

INSERT INTO T2 <-- ma table liée
SELECT * FROM TLocale <-- une table physiquement dans mon mdb

Lorsque que j'espionne le dialogue entre mon poste et SQL Server lors de
l'envoi de cette requête j'obtiens quelque chose du genre:

set implicit transaction on
set identity_insert T2 ON
IDENTITY_INSERT est déjà ON pour la table T1, impossible de définir
IDENTITY_INSERT ON pour la table T2


Est-ce un bug de SQL server?!

Merce d'avance.

6 réponses

Avatar
Fred BROUARD
non, il te dit que comme T2 est en identity insert il ne peut pas le replacer
dans ce mode.
Dans ton script de test tu devrais faire :


SET IDENTITY_INSERT T1 OFF
go

SET IDENTITY_INSERT T2 ON
go

INSERT INTO T2(C1, C2) VALUES(1,2)
go

SET IDENTITY_INSERT T2 OFF
go

Il convient de toujours rétablir l'auto insertion après avoir fairt de
l'insertion excplicté de clef auto inc.

A +

DORAK a écrit:
Bonjour,

Quand j'envoie ces commandes depuis l'analyseur de requêtes sous SQL Server
2000:



> SET IDENTITY_INSERT T1 OFF
> go
> SET IDENTITY_INSERT T2 ON
> go
> INSERT INTO T2(C1, C2) VALUES(1,2)
> go

J'ai bien une ligne ajoutée dans ma table T2

Ma table T2 est liée dans une base access.

Dans ma base access sur currentproject.connection.execute j'envoie la
requête suivant:

INSERT INTO T2 <-- ma table liée
SELECT * FROM TLocale <-- une table physiquement dans mon mdb

Lorsque que j'espionne le dialogue entre mon poste et SQL Server lors de
l'envoi de cette requête j'obtiens quelque chose du genre:

set implicit transaction on
set identity_insert T2 ON
IDENTITY_INSERT est déjà ON pour la table T1, impossible de définir
IDENTITY_INSERT ON pour la table T2


Est-ce un bug de SQL server?!

Merce d'avance.




--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Avatar
DORAK
Oui mais SQL Server n'interdit nullement de le définir deux fois ON sur la
même table ou même 10 fois OFF sur des tables différentes.

Si il est resté ON malencontreusement sur une table, comment le vérifier?! :-(

voici précisément ce qui passe sur le réseau:

// Code que j'envoie "manuellement" au serveur.


BEGIN TRANSACTION
SET IDENTITY_INSERT TirePalette OFF
SET IDENTITY_INSERT [Journal des erreurs] ON
COMMIT TRAN

// Code envoyé par mon instruction ADO

set implicit_transactions on
SET IDENTITY_INSERT [Journal des erreurs] ON
IDENTITY_INSERT est d.j. ON pour la table 'Arnaud.dbo.TirePalette'.
Impossible d'effectuer l'op.ration SET pour la table 'dbo.Journal des erreurs'

// et pourtant je l'ai mis OFF juste avant!




"Fred BROUARD" wrote:

non, il te dit que comme T2 est en identity insert il ne peut pas le replacer
dans ce mode.
Dans ton script de test tu devrais faire :


SET IDENTITY_INSERT T1 OFF
go

SET IDENTITY_INSERT T2 ON
go

INSERT INTO T2(C1, C2) VALUES(1,2)
go

SET IDENTITY_INSERT T2 OFF
go

Il convient de toujours rétablir l'auto insertion après avoir fairt de
l'insertion excplicté de clef auto inc.

A +

DORAK a écrit:
> Bonjour,
>
> Quand j'envoie ces commandes depuis l'analyseur de requêtes sous SQL Server
> 2000:
>
> SET IDENTITY_INSERT T1 OFF
> go
> SET IDENTITY_INSERT T2 ON
> go
> INSERT INTO T2(C1, C2) VALUES(1,2)
> go
>
> J'ai bien une ligne ajoutée dans ma table T2
>
> Ma table T2 est liée dans une base access.
>
> Dans ma base access sur currentproject.connection.execute j'envoie la
> requête suivant:
>
> INSERT INTO T2 <-- ma table liée
> SELECT * FROM TLocale <-- une table physiquement dans mon mdb
>
> Lorsque que j'espionne le dialogue entre mon poste et SQL Server lors de
> l'envoi de cette requête j'obtiens quelque chose du genre:
>
> set implicit transaction on
> set identity_insert T2 ON
> IDENTITY_INSERT est déjà ON pour la table T1, impossible de définir
> IDENTITY_INSERT ON pour la table T2
>
>
> Est-ce un bug de SQL server?!
>
> Merce d'avance.
>

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************




Avatar
DORAK
Aussi incroyable que cela puisse paraître, si je réitère l'opération après
une dizaine de minutes d'attente, ça marche systèmatiquement, ne serait-ce
pas un bug de SQL server qui ne mettrait pas à jour en temps réel des
variables systèmes?

Peut-on récupérer la valeur de IDENTITY_iNSERT pour une table?


"Fred BROUARD" wrote:

non, il te dit que comme T2 est en identity insert il ne peut pas le replacer
dans ce mode.
Dans ton script de test tu devrais faire :


SET IDENTITY_INSERT T1 OFF
go

SET IDENTITY_INSERT T2 ON
go

INSERT INTO T2(C1, C2) VALUES(1,2)
go

SET IDENTITY_INSERT T2 OFF
go

Il convient de toujours rétablir l'auto insertion après avoir fairt de
l'insertion excplicté de clef auto inc.

A +

DORAK a écrit:
> Bonjour,
>
> Quand j'envoie ces commandes depuis l'analyseur de requêtes sous SQL Server
> 2000:
>
> SET IDENTITY_INSERT T1 OFF
> go
> SET IDENTITY_INSERT T2 ON
> go
> INSERT INTO T2(C1, C2) VALUES(1,2)
> go
>
> J'ai bien une ligne ajoutée dans ma table T2
>
> Ma table T2 est liée dans une base access.
>
> Dans ma base access sur currentproject.connection.execute j'envoie la
> requête suivant:
>
> INSERT INTO T2 <-- ma table liée
> SELECT * FROM TLocale <-- une table physiquement dans mon mdb
>
> Lorsque que j'espionne le dialogue entre mon poste et SQL Server lors de
> l'envoi de cette requête j'obtiens quelque chose du genre:
>
> set implicit transaction on
> set identity_insert T2 ON
> IDENTITY_INSERT est déjà ON pour la table T1, impossible de définir
> IDENTITY_INSERT ON pour la table T2
>
>
> Est-ce un bug de SQL server?!
>
> Merce d'avance.
>

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************




Avatar
Fred BROUARD
DORAK a écrit:
Aussi incroyable que cela puisse paraître, si je réitère l'opération après
une dizaine de minutes d'attente, ça marche systèmatiquement, ne serait-ce
pas un bug de SQL server qui ne mettrait pas à jour en temps réel des
variables systèmes?

Peut-on récupérer la valeur de IDENTITY_iNSERT pour une table?



non, mais juste le dernier inséré dans la session à l'aide de @@IDENTITY




"Fred BROUARD" wrote:


non, il te dit que comme T2 est en identity insert il ne peut pas le replacer
dans ce mode.
Dans ton script de test tu devrais faire :


SET IDENTITY_INSERT T1 OFF
go

SET IDENTITY_INSERT T2 ON
go

INSERT INTO T2(C1, C2) VALUES(1,2)
go

SET IDENTITY_INSERT T2 OFF
go

Il convient de toujours rétablir l'auto insertion après avoir fairt de
l'insertion excplicté de clef auto inc.

A +

DORAK a écrit:

Bonjour,

Quand j'envoie ces commandes depuis l'analyseur de requêtes sous SQL Server
2000:




> SET IDENTITY_INSERT T1 OFF
> go
> SET IDENTITY_INSERT T2 ON
> go
> INSERT INTO T2(C1, C2) VALUES(1,2)
> go

J'ai bien une ligne ajoutée dans ma table T2

Ma table T2 est liée dans une base access.

Dans ma base access sur currentproject.connection.execute j'envoie la
requête suivant:

INSERT INTO T2 <-- ma table liée
SELECT * FROM TLocale <-- une table physiquement dans mon mdb

Lorsque que j'espionne le dialogue entre mon poste et SQL Server lors de
l'envoi de cette requête j'obtiens quelque chose du genre:

set implicit transaction on
set identity_insert T2 ON
IDENTITY_INSERT est déjà ON pour la table T1, impossible de définir
IDENTITY_INSERT ON pour la table T2


Est-ce un bug de SQL server?!

Merce d'avance.




--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************







--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Avatar
DORAK
Je crois que j'ai trouvé la cause mais pas la solution.

Apparement, les option SET sont définie indépendemment pour chaque
connexion, ce qui peut paraître logique afin qu'un utilisateur de modifie pas
les options définies par un autre.
Or, ADO ne remet pas INSERT_IDENTITY à OFF à la fin de la transaction, il
reste donc ON pour la table sur laquelle il a travaillé précédemment même si
on la redéfinit à OFF "à la main" car on utilise alors une autre connexion
directe(puisque currentdb.connection ne comprend pas cette instruction) qui
n'impacte pas sur la connexion par la base access

Il semblerait qu'au bout de quelques minutes access ou sql ferment la
connexion inactive depuis trop longtemps restaurant ainsi les valeurs des
options de départ.



"Fred BROUARD" wrote:



DORAK a écrit:
> Aussi incroyable que cela puisse paraître, si je réitère l'opération après
> une dizaine de minutes d'attente, ça marche systèmatiquement, ne serait-ce
> pas un bug de SQL server qui ne mettrait pas à jour en temps réel des
> variables systèmes?
>
> Peut-on récupérer la valeur de IDENTITY_iNSERT pour une table?

non, mais juste le dernier inséré dans la session à l'aide de @@IDENTITY


>
>
> "Fred BROUARD" wrote:
>
>
>>non, il te dit que comme T2 est en identity insert il ne peut pas le replacer
>>dans ce mode.
>>Dans ton script de test tu devrais faire :
>>
>>
>>SET IDENTITY_INSERT T1 OFF
>>go
>>
>>SET IDENTITY_INSERT T2 ON
>>go
>>
>>INSERT INTO T2(C1, C2) VALUES(1,2)
>>go
>>
>>SET IDENTITY_INSERT T2 OFF
>>go
>>
>>Il convient de toujours rétablir l'auto insertion après avoir fairt de
>>l'insertion excplicté de clef auto inc.
>>
>>A +
>>
>>DORAK a écrit:
>>
>>>Bonjour,
>>>
>>>Quand j'envoie ces commandes depuis l'analyseur de requêtes sous SQL Server
>>>2000:
>>>
>>
>> > SET IDENTITY_INSERT T1 OFF
>> > go
>> > SET IDENTITY_INSERT T2 ON
>> > go
>> > INSERT INTO T2(C1, C2) VALUES(1,2)
>> > go
>>
>>>J'ai bien une ligne ajoutée dans ma table T2
>>>
>>>Ma table T2 est liée dans une base access.
>>>
>>>Dans ma base access sur currentproject.connection.execute j'envoie la
>>>requête suivant:
>>>
>>>INSERT INTO T2 <-- ma table liée
>>>SELECT * FROM TLocale <-- une table physiquement dans mon mdb
>>>
>>>Lorsque que j'espionne le dialogue entre mon poste et SQL Server lors de
>>>l'envoi de cette requête j'obtiens quelque chose du genre:
>>>
>>>set implicit transaction on
>>>set identity_insert T2 ON
>>>IDENTITY_INSERT est déjà ON pour la table T1, impossible de définir
>>>IDENTITY_INSERT ON pour la table T2
>>>
>>>
>>>Est-ce un bug de SQL server?!
>>>
>>>Merce d'avance.
>>>
>>
>>--
>>Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
>>Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
>>Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
>>************************ www.datasapiens.com *************************
>>
>>

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************




Avatar
Med Bouchenafa
Non, ce n'est pas un problème de SQL Server mais plutot de l'application
ACCESS
Il est fort possible que le code du projet ADP ou le driver utilisé insert
systématiquement un ordre SET IDENTITY_INSERT tableName ON avant toute
insertion
Ce même code devrait insérer un ordre SET IDENTITY_INSERT tableName OFF à la
fin de l'instruction.
Pourquoi ne le fait-il pas ou il le fait incorrectement ?
C'est certainement un problème de cache et c'est le point à investiguer.

Mais sure ce n'est pas un problème SQL Server


--
Bien cordialement
Med Bouchenafa






"DORAK" a écrit dans le message de news:

Aussi incroyable que cela puisse paraître, si je réitère l'opération après
une dizaine de minutes d'attente, ça marche systèmatiquement, ne serait-ce
pas un bug de SQL server qui ne mettrait pas à jour en temps réel des
variables systèmes?

Peut-on récupérer la valeur de IDENTITY_iNSERT pour une table?


"Fred BROUARD" wrote:

non, il te dit que comme T2 est en identity insert il ne peut pas le
replacer
dans ce mode.
Dans ton script de test tu devrais faire :


SET IDENTITY_INSERT T1 OFF
go

SET IDENTITY_INSERT T2 ON
go

INSERT INTO T2(C1, C2) VALUES(1,2)
go

SET IDENTITY_INSERT T2 OFF
go

Il convient de toujours rétablir l'auto insertion après avoir fairt de
l'insertion excplicté de clef auto inc.

A +

DORAK a écrit:
> Bonjour,
>
> Quand j'envoie ces commandes depuis l'analyseur de requêtes sous SQL
> Server
> 2000:
>
> SET IDENTITY_INSERT T1 OFF
> go
> SET IDENTITY_INSERT T2 ON
> go
> INSERT INTO T2(C1, C2) VALUES(1,2)
> go
>
> J'ai bien une ligne ajoutée dans ma table T2
>
> Ma table T2 est liée dans une base access.
>
> Dans ma base access sur currentproject.connection.execute j'envoie la
> requête suivant:
>
> INSERT INTO T2 <-- ma table liée
> SELECT * FROM TLocale <-- une table physiquement dans mon mdb
>
> Lorsque que j'espionne le dialogue entre mon poste et SQL Server lors
> de
> l'envoi de cette requête j'obtiens quelque chose du genre:
>
> set implicit transaction on
> set identity_insert T2 ON
> IDENTITY_INSERT est déjà ON pour la table T1, impossible de définir
> IDENTITY_INSERT ON pour la table T2
>
>
> Est-ce un bug de SQL server?!
>
> Merce d'avance.
>

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************