Discussion :

[Oluha]

Bonjour

Je viens du forum ASP et on me renvoie ici pour mon problème.

En effet je développe un intranet permettant de gérer des abonnements. Plusieurs personnes l'utilisent en même temps. Elle peuvent créer des abonnés. L'ajout se fait dans deux tables : INDIVIDU (contenant le numéro d'abonné plus d'autres infos) et ADRESSE (liée à INDIVIDU par le numéro d'abonné).
Quand je crée un abonné, j'insère donc d'abord les données dans INDIVIDU puis ADRESSE. Il me faut donc entre les deux récupéré l'id généré automatiquement dans INDIVIDU pour insérer ensuite les infos dans ADRESSE.
Mon problème c'est que plusieurs personnes peuvent créer un abonné en même temps et j'ai un gros doute sur la fiabilité de @@INDENTITY. Est-ce qu'il va vraiment me renvoyer le bon id ou y'a-t-il un risque ?
J'ai lu la doc et ils parlent de session mais je ne sais pas du tout comment c'est géré, donc j'aimerai confirmation : est-ce qu'il est possible qu'un utilisateur ne récupère pas le bon id avec cette requête si un autre a fait une insertion en même temps ? Si oui, comment faire pour être certain de récupérer le bon id ?

Merci

[Thomad]

Session au sens MS SQL. Quand tu te connectes à MS SQL, tu ouvres "une session".
Il n'y a aucun risque à utliser @@Identity juste après ton Insert bien sûr.
A+

[Oluha]

Donc si j'ai bien compris :

Si :
A fait un INSERT
B fait un INSERT
A fait SELECT @@IDENTITY

Il n'y aura aucun problème ?

[Thomad]

C'est qui A ?
C'est qui B ?

[Oluha]

Bon je sais mes questions sont bêtes mais j'ai pas envi de me faire taper sur les doigts parce que mon truc marche pas.

Donc à priori A et B devraient être deux utilisateurs différents sur mon intranet mais je ne sais absolument pas comment c'est géré après au niveau des utilisateurs dans SQL SERVER.

[Thomad]

Dans ta page asp , peu importe A ou B , il y a code du SQL, non !

Quand tu fais ton insert into ... // pour INDIVIDU
De suite tu fais ton Select @@Identity
Cette valeur (celle du Select @@Identity ) tu dois la récupérer
Ensuite tu continues ton insert into .. // pour ADRESSE
et tu places dans la Table ADRESSE , ID récupéré avec Select @@Identity

Ta table INDIVIDU doit être du genre:
IDIndividu , Nom , Prenom etc...

Ta table ADRESSE doit être du genre:
IDAdresse , IDIndividu , etc...

[Oluha]

D'accord mais ca ne posera pas de problème si deux personnes sur l'intranet ajoute un individu en même temps ?

Donc si j'ai bien compris : si dans mon code ASP j'ai le INSERT et le SELECT à suivre (ce qui est le cas), si les utilisateurs A et B envoient ces requêtes exactement en même temps, SQL SERVEUR va bien faire :
INSERT A
SELECT A
INSERT B
SELECT B

Ou alors peut importe ?
Ce que je ne sais pas c'est si A et B ont des sessions différentes sur SQL server et donc il n'y a aucun risque ou bien la session est la même car ils viennent tous les deux du server IIS ?

[Thomad]

Ce que je ne sais pas c'est si A et B ont des sessions différentes sur SQL server

"Session MSSQL" n'a rien à voir avec tes sessions ASP.
Le moteur MSSQL va avoir à traiter des requêtes SQL et quand tes requêtes arrivent via ASP tu fais bien d'abord une connection (je ne sais plus le code car je suis php !) .
Cette connection ou session elle sert pendant toutes tes requêtes SQL.
Si en plus tu fais un

BEGIN TRANSACTION

ici ton insert puis ton @@identity et pour finir ton autre insert

COMMIT TRANSACTION

en cas de pépins ton INDIVIDU ne sera pas enregistré , ni son ADRESSE

PS: à voir peut-être l'histoire de l'autocommit

A+

[Oluha]

Ok je ne connaissais pas "BEGIN TRANSACTION" et "COMMIT TRANSACTION", je vais essayer de me renseigner sur la facon d'écrire ca en ASP, merci