Requête pour obtenir l'identité suivante?
Requête pour obtenir l'identité suivante? C'est possible pour la table sans enregistrements supprimés:
SELECT TOP 1 EMPID + 1 FROM Employee ORDER BY EMPID DESC
Si il est supprimé des données, Comment vais-je obtenir l'identité suivante ? Par exemple, j'ai un tableau comme ceci:
EMPID NAME
4001 someName
4002 someName
4003 ----------------------- this is deleted
4004 someName
4005 someName
4006 someName
4007 someName
4008 someName
4009 ----------------------- this is deleted
4010 ----------------------- this is deleted
La sortie doit être 4011
- Seulement un commentaire mais pourquoi avez-vous besoin? Pourquoi ne pas effectuer l'insertion et les récupérer à l'aide de la technologie iden scope_identity?
- Sera utiliser dans mon application winform pour afficher le prochain EmpID
- Peut-être une question stupide... mais pourquoi voulez-vous afficher la prochaine
EmpID
? - C'est insensé. Si vous effectuez une requête pour obtenir ce que l'identité suivante pourrait être par le temps, vous finirez par faire une insertion, une autre personne peut avoir généré une nouvelle valeur (soit validée ou annulée), ce qui rend votre supposition tout à fait inexacte. Quel est le point de montrer l'ID de toute façon? Les valeurs d'identité doit être transparente des mères porteuses que les utilisateurs finaux n'ont pas besoin de connaître ou de se soucier. S'ils le font, puis valider l'insertion, puis montrez-leur ce qu'ils ont obtenu, au lieu de leur montrer ce qu'ils pourraient obtenir.
- SQL Server n'a pas de "recycler" les valeurs d'identité supprimées - et c'est une BONNE chose!
- Dans mon application un utilisateur insère un livre. Par exemple someBook sera insert avec 3 exemplaires. Table1.BookID = 1, Table1.Copie = 3, Puis dans une autre table, ces 3 livres ont leur clé primaire de sorte qu'il sera de Table2.AccessionID = 1,2,3 Table2.BookID = 1, 1, 1.
- C'est faux à bien des niveaux, et l'on a accepté la réponse ne va pas vous faire des faveurs, quand vous avez réellement tester avec plusieurs utilisateurs. 🙁
- Alors, quelle est la meilleure façon de le faire?
- Effectuer l'insertion d'abord, puis de l'afficher sur votre formulaire. Pourquoi est-ce que votre utilisateur besoin de savoir ce que l'ID de la valeur qu'ils reçoivent avant que vous avez attribué à le leur? Comment est-ce aider si c'est mal?
- Voir mon premier commentaire! Effectuer l'insertion et ENSUITE récupérer la réelle iden valeur utilisée.
- Je pense que la requête ci-dessus est assez bon parce que l'utilisateur ne sera pas autorisé à supprimer des enregistrements, à la place d'une Colonne de quelque chose comme le Statut sera mis à jour avec la valeur
Deleted
- et si un autre utilisateur insère un enregistrement entre le moment de l'utilisateur, puis vos données devient de déformation
- vous êtes complètement à côté de la question. Simuler deux utilisateurs de votre application par l'ouverture de deux fenêtres management studio. Dans chacun exécuter votre
IDENT_CURRENT
de requête de sortie et les résultats. Maintenant, insérez-la dans la table dans une fenêtre, et ensuite l'insérer dans l'autre, dans les deux cas, vérifierSCOPE_IDENTITY()
. Il est 100% impossible pour eux deux pour correspondre à laIDENT_CURRENT
de sortie, mais vous avez montré à la fois les utilisateurs d'identification que sur la forme. Notez que dans aucune session ne vous supprimez quelque chose.
Vous devez vous connecter pour publier un commentaire.
La seule façon pour vous de montrer de manière fiable une
IDENTITY
valeur sur le formulaire de votre application est à INSÉREZ d'ABORD.IDENT_CURRENT
peut sembler pour vous aider lorsque vous êtes la seule personne à le tester, mais je peux vous assurer que cela va s'effondrer très rapidement une fois plusieurs utilisateurs à l'aide de votre application. Il est très facile de prouver que, trop. Créer le tableau suivant:Maintenant, dans deux fenêtres Management Studio, tout d'abord exécuter ce code, qui permet de simuler ce que vous souhaitez être visible sur le formulaire, si vous suivez les accepté de répondre et ce que vous avez dit "œuvres":
Noter la sortie (les deux doivent être
1
). Cela est correct. JUSQU'À PRÉSENT.Maintenant, dans une fenêtre, exécutez ceci:
La sortie doit être
1
(qui, rappelons-le, est correcte jusqu'à PRÉSENT).Maintenant, dans l'autre fenêtre, exécutez la même chose, mais le changement
x
ày
. Cette sortie est maintenant2
. UH-OH. Cela ne correspond pas à ce que vous a montré cet utilisateur dans le formulaire. Vous pouvez également vérifier que en voyant il y a deux lignes dans la table, avec1
et2
comme leIDENTITY
valeurs:La bonne façon de le faire, et la seule façon de le faire est d'insérer une ligne, de récupérer la valeur, et puis l'afficher sur le formulaire. Si vous avez besoin de leur montrer la valeur de substitution à l'avance (aucune idée de pourquoi vous avez besoin de le faire, ou pourquoi vos utilisateurs finaux ont besoin de connaître cette valeur, peu importe quand vous le retrouver - pourquoi les utilisateurs de soins de ce que l'ID est?), ensuite, créez une table séparée et de générer votre
IDENTITY
valeurs.Maintenant, si vous souhaitez montrer le "prochain" ID sur le formulaire, vous pouvez le faire en utilisant les suivantes:
Ensuite, lorsque l'utilisateur remplit le reste de l'information, vous pouvez insérer dans
dbo.real_table
et comprennent laID
colonne dans l'insertion de la liste, à l'aide de la valeur que vous avez récupéré à partir dedbo.dummy_table
. Notez que cela va encore se retrouver avec des lacunes dans l'hypothèse où un utilisateur a vu un ID et n'a pas de cliquer sur enregistrer, mais que l'ID est maintenant vide de sens comme il ne l'a jamais fait dans la "vraie" table - et il n'est pas possible pour quiconque d'avoir vu (à la différence de ce qui peut arriver avecIDENT_CURRENT
,MAX+1
et d'autres mal pensé "vérifier la valeur de la première" techniques).Si votre objectif est d'insérer des trois exemplaires du livre dans une autre table, la solution est assez simple, et nécessite toujours que vous insérez le livre d'abord. Supposons que vous avez les paramètres pour représenter le nom du livre et le nombre de copies (ainsi que d'autres paramètres, j'en suis sûr):
Maintenant, nous pouvons insérer dans la
dbo.Books
table, et l'utilisation de la sortie pour insérer plusieurs lignes dans l'autre table (dbo.Accession
?). Pas besoin de deviner aveuglément à la "prochaine" de la valeur deBookID
premier.Il utilise une astuce pour générer plusieurs lignes de vues de catalogue, mais vous pouvez également utiliser un haut-
Numbers
tableau, si vous en avez un, pour l'amélioration de l'efficacité (et moins restrictives pour les autorisations).x
, qui est la prochaine valeur d'identité avant de m'insérer, et copiez-la dans une autre tablen
fois." Qu'est-ce quex
?x
n'est pasthe book
.x
est ce que vous êtes en train d'essayer de faire.Ont un coup d'oeil à SQL SERVER – @@IDENTITY vs SCOPE_IDENTITY() vs IDENT_CURRENT – Récupérer la Dernière Inséré l'Identité de l'Enregistrement
Veuillez noter les différences, comme stqated ci-dessous.
Je recommanderais vous regardez à l'aide de IDENT_CURRENT.
IDENT_CURRENT (Transact-SQL)
SCOPE_IDENTITY (Transact-SQL)
@@IDENTITY (Transact-SQL)
IDENT_CURRENT
? Comme je l'ai indiqué dans ma réponse, cela peut donner de très mauvais résultats si il y a plus d'un utilisateur.