Comment verrouiller une table pour insertion en SQL?

Question

J'ai une application web dans laquelle j'ai une page nommée 'Data'. Beaucoup de gens vont essayer d'insérer des données dans la table à un moment donné. Ainsi, la référence autre que la clé primaire sera dupliquée ce qui ne devrait pas être autorisé. Pour insérer les données dans la table DB, j'utilise une procédure stockée dans SQL. Dans mon application Web vb.net, j'utilise la couche Business avec la bibliothèque d'entreprise pour appeler la procédure stockée. Maintenant, je veux verrouiller la table pour l'insertion de sorte que lorsque plusieurs utilisateurs insèrent, il n'y aura pas de complications. Comment puis-je faire ceci? S'il vous plaît donnez votre avis.

Je ne voulais pas dire la clé primaire. J'ai un champ clé primaire à savoir InvoiceID qui n'est pas dupliqué. Mais avec cela, j'ai besoin d'un 'InvoiceNo' qui ne devrait pas être dupliqué aussi bien. Celui-ci est automatiquement renseigné à partir de la 'FactureNo' + 1 précédemment entrée qui sera dupliquée lorsque plusieurs utilisateurs tentent d'insérer en même temps.

Cordialement

Answer 1

Quelles sont les complications qui vous préoccupent? Les INSERT simultanés fonctionnent généralement correctement sans verrouillage explicite.

Answer 2

Pourriez-vous juste préciser exactement le problème. Peut-être que je ne comprends pas. Toutefois, si vous avez une clé primaire définie avec Identity Insert dans la base de données, vous pouvez appeler votre procédure stockée Insert autant de fois que vous le souhaitez (dans des limites raisonnables) et SQL Server s'assurera que chacun est inséré correctement. Tant que vous n'êtes pas trop inquiet de l'ordre exact, ils sont insérés ou quelque chose comme ça.

Si vous commencez à verrouiller la table, vous commencez à rencontrer des problèmes d'attente et d'attente. Il vaut mieux tout jeter sur SQL Server et laisser manipuler tous les inserts - c'est plus que capable de le faire pour vous.

Excuses si cela n'a pas répondu à la question.

Answer 3

Ne pas. N'y pense même pas. Vous allez tuer toute performance et concurrence que vous avez.

Vous devez savoir pourquoi vous avez des valeurs PK en double. Si vous laissez cela à la base de données elle-même, en utilisant une colonne INT IDENTITY par exemple, vous n'avez vraiment rien à craindre. SQL Server veillera à ce que ces valeurs soient toujours uniques. Donc, la recommandation est la suivante: réorganiser votre solution et laisser la base de données gérer l'unicité de l'ID - alors vous n'aurez aucun besoin de tout verrouillage ou quoi que ce soit.

Answer 4

Je comprends parfaitement traiter avec les comptables qui ne veulent pas que le numéro de facture indiqué au client soit la clé primaire - ne serait pas étonné de constater que votre "numéro de facture" est réellement supposé être une chaîne composée de, disons, client # suivi de tiret suivi de leur numéro de facture, ou quelque chose comme ça. Peut-être pourriez-vous utiliser une table supplémentaire que vous référenciez à l'intérieur d'un trigger au lieu d'insert sur votre table de factures. Vous devrez, hélas, permettre au déclencheur de ralentir vos inserts jusqu'à la performance au niveau du curseur; Mais la plupart des cas de facturation que je connais ne généreraient pas un nombre important de factures simultanément avec des contraintes de temps critiques et sub-minute. Tu ferais quelque chose comme ça ...

créer invoiceNumbers de table (invNumber int pas l'identité null clé primaire)

Ensuite, vous feriez un lieu de déclencheur d'insertion sur votre table de factures qui itérer la table insérée avec un curseur; pour chaque ligne, il insère une nouvelle ligne sur invoiceNumbers, récupère la valeur scope_identity(), puis insère la facture (avec le nouveau numéro de facture) dans la table des factures.Cela ralentirait vos factures en insérer quelques-uns mais vous ne seriez pas dans un problème de concurrence, ce qui est bien pire que d'un problème de vitesse-curseur-plutôt-que-set-logique-vitesse.