SQL Server - est de l'utilisation de @@ROWCOUNT en sécurité dans des applications multithread?

Je suis à l'aide de SQL Server 2008.

J'ai une table Un qui accepte de nombreux insérer/mettre à jour en une seconde. Après l'insertion, mise à jour, je veux obtenir le nombre de lignes affectées.

INSERT INTO A (ID) VALUES (1)
IF @@ROWCOUNT = 0
    PRINT 'NO ROWS AFFECTED'

Alors que l'exécution de la requête, la même requête peut être appelé à nouveau par l'application. Donc ce qui arrive si l'exécution en cours est après l'INSERTION, mais avant SI le bloc à ce moment.

Pensez-vous @@ROWCOUNT peut donner un mauvais résultat pour cette raison?

Ou est-il toujours en sécurité dans son contexte?

OriginalL'auteur Ahmet Altun | 2012-01-22

21

Oui - son coffre. Il se réfère toujours l'opération précédente dans la requête actuelle

MAIS

si vous voulez connaître le nombre de lignes affectées, enregistrer dans la variable première, parce que, après IF déclaration du comte @@ROWCOUNT réinitialise
```
INSERT INTO A (ID) VALUES (1)
DECLARE @rc INT = @@ROWCOUNT
IF @rc = 0
    PRINT 'NO ROWS AFFECTED'
ELSE
  SELECT @rc AS RowsAffected
```
OriginalL'auteur Oleg Dok
7

@@ROWCOUNT est à la fois la portée et la connexion coffre-fort.

En fait, il ne lit que la dernière déclaration de nombre de ligne pour la connexion et la portée. Les règles complètes sont ici sur MSDN (curseurs, DML, EXÉCUTER, etc)

De l'utiliser dans les instructions suivantes, vous devez le stocker dans une variable locale.

OriginalL'auteur gbn
1

Vous doit préserver la @@ROWCOUNT valeur dans une variable locale, sinon après la IF déclaration de sa valeur sera remis à zéro:
```
SET @rowCount = @@ROWCOUNT

IF @rowCount = 0 
   PRINT 'NO ROWS AFFECTED' 
```
Autres que que, oui, c'est sûr.

Je viens de tester cela sur MS SQL 2008 R2 DB et la IF de contre-vérifier les @@ROWCOUNT a fonctionné sans problème. Je peux comprendre que cela pourrait être une bonne pratique de toujours stocker localement @@ROWCOUNT avant de faire quelque chose avec elle. Mais pourquoi avez-vous dit que vous avez dans un premier temps de le stocker dans une variable locale? Avez-vous tout simplement dire que c'est une bonne pratique ou est-il réellement fiable de contrôler directement la valeur de @@ROWCOUNT?
Vous devez le stocker de la valeur avant d'y accéder.
J'ai fait un peu de recherche pour trouver des références qui indiquent que c'est nécessaire, mais je n'ai pas trouvé. Est-il une référence ou la source que vous pouvez fournir pour démontrer qu'il est nécessaire de faire cela?
En effet, les exemples de toutes les versions SQL 2005-2012 sur MSDN* ne pas stocker @@ROWCOUNT avant de référencer dans une instruction if. Je suis intéressé par une source qui prouve MSDN est incorrect. * technet.microsoft.com/en-us/library/ms187316.aspx

OriginalL'auteur Mitch Wheat
0

Réponse courte: Oui.

Cependant, il vaut la peine de voir la question sous un point de vue, pour le plus profond de comprendre pourquoi la réponse oui est si naturelle, sans doute.

SQL Server est préparé à gérer les accès simultanés correctement, de par sa nature, peu importe si le client demande est multithread ou pas. À moins que cet attribut SQL Server serait inutile dans tout scénario multi-utilisateur. Du point de vue du serveur, il n'a pas d'importance si l'accès simultané à causées par un application multithread, ou deux applications qui sont actuellement à l'aide du serveur simultanément par plusieurs utilisateurs.

Sur ce point l' @@rowcount n'est que la partie visible de l'iceberg, il y a de plus profond et de plus la fonctionnalité de ce qui doit être géré correctement lors de l'accès simultané est dans l'image.

La plupart partie pratique de ce domaine est la gestion des transactions et de l'isolation de la transaction.

OriginalL'auteur g.pickardou

Vous devez vous connecter pour publier un commentaire.