DataReader et SQLCommand

Question

Comme on dit sur la radio - appelant longue durée premier appelant ....

Voici mon problème. VS 2005 SQL Server 2005 Database. Application Windows Forms C#. Grande table - 780K dossiers. Je l'appellerai la table source. Vous devez faire une boucle dans la table source, et pour chaque enregistrement, faire quelque chose avec une autre table, puis réécrire dans la table source qu'elle a été complétée. Je n'ai pas encore mis à jour la deuxième table ...

Je parcourt tous les enregistrements de la table source à l'aide d'un lecteur de données à l'aide de l'objet de connexion A. Pour chaque enregistrement, je crée une instruction de mise à jour pour mettre à jour la table source pour indiquer que cet enregistrement a été traité - et utilisez une commande SQL par rapport à l'objet de connexion B pour effectuer cette opération. Donc différents objets de connexion car je sais que le dataReader veut une exclusivité.

Voici le problème. Après avoir traité les enregistrements X - où X semble avoir environ 60 ans - le délai d'attente de mise à jour. En écrivant ceci - drôle comment cela se passe n'est-ce pas - mon cerveau me dit que cela a à voir avec l'isolation des transactions et/ou le verrouillage ... c.-à-d. Je suis en train de lire les enregistrements source en utilisant un lecteur de données mais en changeant ces enregistrements ... Je peux voir cela causer des problèmes avec différentes isolations de transaction donc je vais regarder dans ...

Quiconque a vu ceci et sait comment résoudre il?

Vive

Pete

Answer 1

Sans plus de détail, les possibilités de solutions sont très nombreuses. Comme iivel l'a noté, vous pouvez effectuer toutes les activités dans la base de données elle-même - si cela est possible pour le type d'opérations que vous devez effectuer. J'ajouterais simplement qu'il serait très probablement préférable de faire une telle chose en utilisant des opérations basées sur des ensembles plutôt que des curseurs.

Si vous devez effectuer cette opération en dehors de la base de données, alors votre requête source peut être exécutée sans verrous du tout, si c'est une chose sûre à faire dans votre cas. Vous pouvez le faire en définissant le niveau d'isolation ou en ajoutant simplement with (nolock) après le nom de votre table/alias dans la requête.

Il existe plusieurs autres options. Par exemple, vous pouvez opérer par lots, par exemple, en extrayant 1000 enregistrements à la fois de la table source en mémoire, en vous déconnectant, puis en effectuant toutes les opérations et mises à jour dont vous avez besoin. Une fois tous les 1000 enregistrements traités, travaillez sur un autre ensemble de 1000 enregistrements, et ainsi de suite, jusqu'à ce que tous les enregistrements de la file d'attente aient été traités.

Answer 2

Sons comme vous devez définir le délai d'attente propery commande sur l'objet de commande.

Answer 3

Y a-t-il une raison pour laquelle vous ne pouvez pas avoir les sélections/mises à jour dans un curseur et retourner un résultat final à l'application? Si le processus appartient à la base de données, il est préférable de le conserver.

La mise à jour alternée de la commande, comme John l'a mentionné, est votre seul autre pari.