Discussion :

[jubourbon]

Bonjour,

Je souhaites enregistrer des informations dans un base sql depuis un formulaire sur une page ASP.Net
J'utilise pour ca ADO.Net.
J'insère dans une table Personne un nom et un prénom. Chaque enregistrement de cette table possède un id qui s'autoincremente.
J'aurais besoin une fois enregistrer de récupérer cet ID du cet élément que je viens d'insérer.

Je prévois de faire une requête qui me renvoi le dernier élément enregistré,mais c'est pas très sur en cas d'enregistrement simultané et c'est pas top.

Pourriez vous me conseiller une autre méthode?

[Redouane]

Bnj,

J'espère que ça va t'aider :

http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx

Bonne courage.

[Bluedeep]

Pourriez vous me conseiller une autre méthode?

- Faire une proc stoc réalisant l'insertion et retournant l'id recupéré avec la fonction @@identity, qui sera retourné dans un paramètre OUTPUT de la proc stoc (le code de retour devant plutôt être réservé à une information de type ok/ko , même si techniquement rien n'empêche de l'utiliser pour cet usage).

- Questionner le fait d'avoir besoin de champs incrémentaux : si c'est un élement d'identication "métier" (numéro de client par exemple) ça se justifie, si c'est un élément d'unicité technique uniquement, un uniqueidentifier me semble bien plus adapté et peut être généré par le code client.

[jubourbon]

Merci pour ton aide, cette page est bien complète et je ne l'avais pas rencontrée avant.

[ostenhard]

- Faire une proc stoc réalisant l'insertion et retournant l'id recupéré avec la fonction @@identity, qui sera retourné dans un paramètre OUTPUT de la proc stoc (le code de retour devant plutôt être réservé à une information de type ok/ko , même si techniquement rien n'empêche de l'utiliser pour cet usage).

- Questionner le fait d'avoir besoin de champs incrémentaux : si c'est un élement d'identication "métier" (numéro de client par exemple) ça se justifie, si c'est un élément d'unicité technique uniquement, un uniqueidentifier me semble bien plus adapté et peut être généré par le code client.

Euh, il faut tout de même faire attention avec @@identity, selon moi, il convient mieux d'utiliser scope_identity (cf l'extrait de MSDN à ce sujet)

SCOPE_IDENTITY
Returns the last identity value within the current execution scope. SCOPE_IDENTITY is recommended for most scenarios.

@@IDENTITY
Contains the last identity value generated in any table in the current session. @@IDENTITY can be affected by triggers and may not return the identity value that you expect.

IDENT_CURRENT
Returns the last identity value generated for a specific table in any session and any scope.

[Bluedeep]

Euh, il faut tout de même faire attention avec @@identity, selon moi, il convient mieux d'utiliser scope_identity (cf l'extrait de MSDN à ce sujet)

Dans l'absolu tu as tout à fait raison, mais cela n'a de réalité concréte que dans une architecture avec un environnement de réplication (dans la mesure où tu utilise la fonction dans l'instruction suivant l'insertion), or je ne pense pas que cela soit le cas ici.

Mais tu as parfaitement raison de souligner la nuance.

Microsoft dit :

@@IDENTITY is not a reliable indicator of the most recent user-created identity if the column is part of a replication article.