Perte de la connexion ODBC avec la base de données SQL Server 2005

Question

L'un de nos clients dispose d'une application (FoxPro 9) exécutée sur un backend SQL Server 2005. Par intermittence, ils perdent leur connexion ODBC avec la base de données SQL Server. Ci-dessous sont les informations d'erreur initiale:

Err Msg: Connectivity error: [Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionRead (recv()).

ODBC Err Msg: [Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionRead (recv()).

SQL State: 01000

ODBC Err No: 10054

ODBC Handle: 1

FoxPro Error No: 1526

Nous ne pouvons pas dupliquer cette erreur sur commande. Nous avons essayé un certain nombre de solutions en vain. Une telle solution de base matérielle que nous avons trouvé a été décrite dans: http://support.microsoft.com/kb/942861/en-us

Je mentionne cela parce qu'il correspond presque parfaitement à ce que nous avons vu. Cependant, nous avons implémenté toutes les solutions de contournement répertoriées dans cette publication (et dans celui-ci http://support.microsoft.com/kb/948496) - et le problème persiste toujours.

Ce problème semble se manifester après l'exécution de requêtes longues, mais nous ne recevons aucune erreur de délai d'attente, que ce soit de la part de l'application ou de SQL Server. Je ne crois pas que ce soit le résultat d'un délai d'inactivité, car il se produit parfois au milieu d'un programme en cours d'exécution.

Je ne suis pas un mec du matériel, mais le réseau et le serveur (Windows Server 2003) semblent être rapides et bien conçus. Il y a cependant des moments où le serveur de base de données subit un stress important.

Si quelqu'un a des suggestions sur des choses que nous pourrions essayer ... s'il vous plaît laissez-nous savoir!

Answer 1

Juste un coup dans le noir, mais avez-vous essayé d'exécuter une trace et essayer de capturer les événements d'erreur ainsi que tout tsql. Cela pourrait fournir des indices ou vous aider à voir un motif.

Answer 2

Juste un suivi sur cette question ... avec une solution partielle.

J'ai fait une trace, en fait un certain nombre d'entre eux. Ce que j'ai trouvé, c'est qu'il semble y avoir plusieurs causes à ces erreurs. J'ai pu trouver et corriger l'un d'eux, mais nous avons toujours cette erreur dans d'autres endroits, et ils n'apparaissent pas sur les traces que j'ai faites.

Alors, quel était le problème avec celui que j'ai trouvé? Eh bien, de la trace, je trouve que ces erreurs ODBC sont apparus après une autre erreur SQL Server:

Error: 1203, Severity: 20, State: 1. 
Process ID 94 attempted to unlock a resource it does not own: OBJECT: 25:1699834390:0 . Retry the transaction, because this error may be caused by a timing condition. If the problem persists, contact the database administrator. 

À partir du code FoxPro J'ai trouvé qu'une déclaration d'insertion a été à l'origine de cette erreur ... pas toujours ... mais parfois. Dans cet encart, ils tiraient tous les champs d'une table, et certains des champs d'une autre table - dans une troisième table. Chaque table de cette base de données possède une colonne d'identité appelée id_col et l'instruction select qui peuplait la troisième table renvoyait deux champs id_col. Lorsque nous avons restructuré le code de sorte qu'un seul id_col ait été renvoyé ... les erreurs se sont arrêtées.

Pour être honnête, il y a un autre contributeur possible à cette erreur que j'ai corrigé en même temps. Il y avait une autre grande/longue requête juste avant celle-ci qui utilisait la syntaxe Foxpro Rushmore (par exemple a.item+a.customer = lc_item+lc_customer) dans une requête SQL Server. Nous avons eu des problèmes avec ce genre de chose auparavant, donc cela pourrait contribuer au problème ... mais la preuve est fortement en faveur de la colonne d'identité supplémentaire étant la cause.

Answer 3

Vous ne savez pas si vous avez trouvé une solution complète, mais avez-vous vérifié si la connexion réseau était interrompue? L'un des programmes VFP que je développais a commencé à perdre sa connexion SQL très fréquemment pour les utilisateurs qui utilisaient des ordinateurs portables. Il semblait que les ordinateurs portables étaient temporairement perdre la connexion réseau. Même si la connexion n'est interrompue que quelques secondes, la poignée de VFP doit être réinitialisée. Je ne sais pas si c'est votre problème exact, mais cela m'a semblé similaire.

Answer 4

Utilisation de l'application pb et de ms sql comme db, et de 2 objets de transaction définis depuis le début. Une fonction parcourt un curseur en utilisant la première transaction et dans cette boucle, le deuxième objet de transaction est utilisé pour mettre à jour une autre table. Si une validation explicite n'est pas utilisée après la mise à jour (la deuxième transaction obj), la première connexion est arrêtée et j'obtiens l'erreur [Microsoft] [Pilote ODBC SQL Server] [DBNETLIB] ConnectionRead (recv()). Une fois que j'ai appelé l'instruction de validation appropriée pour la transaction correspondante, tout a fonctionné comme un charme. Et OUI, l'erreur est toujours quelque part avant l'emplacement où vous avez réellement le crash-en supposant que vous êtes en mode de débogage. Il est intéressant que Sybase ait réussi à fermer/ouvrir la transaction appropriée sans avoir besoin d'émettre explicitement un commit sur le second objet de la transaction !!!!