Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Windows Windows Serveur SQL Serveur @@Identity avec réplication

@@Identity avec réplication

3 réponses
Avatar
Larigue
Bonjour.

Nous utilisons SQL SERVER 2005 SP2 pour une réplication de fusion entre 2
tables identiques coté editeur et coté abonné.

Cette table a une colonne identité (avec not for réplication)

Le problème est le suivant :
Aprés l'aplication de la capture instantanée, nous inserons des lignes coté
Abonné
puis procédons à la synchronisation. tout va bien, les nouvelles lignes sont
insérées coté Editeur.
Maintenant lorsque l'on insère une nouvelle ligne coté abonné, la ligne est
insérée avec un nouvel identifiant correct, MAIS la fonction @@IDENTITY
retourne une valeur d'identifiant incohérente.
Et nous avons besoin de cette valeur afin d'insérer d'autres lignes
relationelles dans une autre table avec cette nouvelle valeur d'identifiant.
Nous sommes donc bloqués.
Quelqu'un aurait-il une idée ?
Merci
Signaler un problème avec ce contenu

3 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Patrice
Cf SCOPE_IDNEITY dans la doc. Extrait :

SCOPE_IDENTITY et @@IDENTITY renvoient les dernières valeurs d'identité
générées dans une table de la session active. Toutefois, SCOPE_IDENTITY
renvoie les valeurs insérées uniquement dans l'étendue actuelle. @@IDENTITY
n'est pas limitée à une étendue spécifique.

---
Patrice


"Larigue" a écrit dans le message de
news:
Bonjour.

Nous utilisons SQL SERVER 2005 SP2 pour une réplication de fusion entre 2
tables identiques coté editeur et coté abonné.

Cette table a une colonne identité (avec not for réplication)

Le problème est le suivant :
Aprés l'aplication de la capture instantanée, nous inserons des lignes
coté
Abonné
puis procédons à la synchronisation. tout va bien, les nouvelles lignes
sont
insérées coté Editeur.
Maintenant lorsque l'on insère une nouvelle ligne coté abonné, la ligne
est
insérée avec un nouvel identifiant correct, MAIS la fonction @@IDENTITY
retourne une valeur d'identifiant incohérente.
Et nous avons besoin de cette valeur afin d'insérer d'autres lignes
relationelles dans une autre table avec cette nouvelle valeur
d'identifiant.
Nous sommes donc bloqués.
Quelqu'un aurait-il une idée ?
Merci


Avatar
Marcus
ok pour SCOPE_IDENTITY.
Mais le meme probleme survient avec un recordset ADO.
C'est a dire que apres un insert dans une table, l'identifiant retourné dans
l'ADODB recordset est incorrect...

"Patrice" a écrit :

Cf SCOPE_IDNEITY dans la doc. Extrait :

SCOPE_IDENTITY et @@IDENTITY renvoient les dernières valeurs d'identité
générées dans une table de la session active. Toutefois, SCOPE_IDENTITY
renvoie les valeurs insérées uniquement dans l'étendue actuelle. @@IDENTITY
n'est pas limitée à une étendue spécifique.

---
Patrice


"Larigue" a écrit dans le message de
news:
> Bonjour.
>
> Nous utilisons SQL SERVER 2005 SP2 pour une réplication de fusion entre 2
> tables identiques coté editeur et coté abonné.
>
> Cette table a une colonne identité (avec not for réplication)
>
> Le problème est le suivant :
> Aprés l'aplication de la capture instantanée, nous inserons des lignes
> coté
> Abonné
> puis procédons à la synchronisation. tout va bien, les nouvelles lignes
> sont
> insérées coté Editeur.
> Maintenant lorsque l'on insère une nouvelle ligne coté abonné, la ligne
> est
> insérée avec un nouvel identifiant correct, MAIS la fonction @@IDENTITY
> retourne une valeur d'identifiant incohérente.
> Et nous avons besoin de cette valeur afin d'insérer d'autres lignes
> relationelles dans une autre table avec cette nouvelle valeur
> d'identifiant.
> Nous sommes donc bloqués.
> Quelqu'un aurait-il une idée ?
> Merci





Avatar
Patrice
Déjà j'aurais du préciser dans mon message d'avant que le problème se posait
donc par exemple en cas de trigger (l'insertion se fait avec une valeur mais
un trigger qui insére lui-même des données avec un uniqueidentifier mets à
jour @@IDENTITY. SCOPE_INDENTIY permet de récupérer la valeur correcte).

Si le problème persiste, le mieux est sans doute de poser un bout de code
(un formum ADO est peut-êrtre plsu adapté, car SCOPE_IDENTITY fonctionne à
priori et il y a donc plutôt un pb dans la façon de récupérer cet ID avec
ADODB).

--
Patrice

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

ok pour SCOPE_IDENTITY.
Mais le meme probleme survient avec un recordset ADO.
C'est a dire que apres un insert dans une table, l'identifiant retourné
dans
l'ADODB recordset est incorrect...

"Patrice" a écrit :

Cf SCOPE_IDNEITY dans la doc. Extrait :

SCOPE_IDENTITY et @@IDENTITY renvoient les dernières valeurs d'identité
générées dans une table de la session active. Toutefois, SCOPE_IDENTITY
renvoie les valeurs insérées uniquement dans l'étendue actuelle.
@@IDENTITY
n'est pas limitée à une étendue spécifique.

---
Patrice


"Larigue" a écrit dans le message de
news:
> Bonjour.
>
> Nous utilisons SQL SERVER 2005 SP2 pour une réplication de fusion entre
> 2
> tables identiques coté editeur et coté abonné.
>
> Cette table a une colonne identité (avec not for réplication)
>
> Le problème est le suivant :
> Aprés l'aplication de la capture instantanée, nous inserons des lignes
> coté
> Abonné
> puis procédons à la synchronisation. tout va bien, les nouvelles lignes
> sont
> insérées coté Editeur.
> Maintenant lorsque l'on insère une nouvelle ligne coté abonné, la ligne
> est
> insérée avec un nouvel identifiant correct, MAIS la fonction @@IDENTITY
> retourne une valeur d'identifiant incohérente.
> Et nous avons besoin de cette valeur afin d'insérer d'autres lignes
> relationelles dans une autre table avec cette nouvelle valeur
> d'identifiant.
> Nous sommes donc bloqués.
> Quelqu'un aurait-il une idée ?
> Merci