sqlnclir.rll en cours de chargement et de déchargement en continu

Question

Je suis en train de travailler avec SQL Native Client 9 dans une application C++ qui communique avec SQL Server 2000. Je travaille sur le débogage en ce moment mais quelque chose que j'ai remarqué me dérange (car sqlnclir.rll est en cours de chargement et de déchargement en continu et les lignes suivantes sont spammées dans ma fenêtre de sortie de débogage.

'my_app.exe': Loaded 'C:\WINDOWS\system32\sqlnclir.rll', Binary was not built with debug information. 
The thread 'Win32 Thread' (0x9f4) has exited with code 0 (0x0). 
'my_app.exe': Unloaded 'C:\WINDOWS\system32\sqlnclir.rll' 

L'ID après « Win32 thread » modifications mais le code de sortie est toujours 0.

Pourquoi le .rll est ceci et comment chargé et déchargé en permanence comme je peux l'empêcher d'arriver?

Si ce qui précède n'est pas une question possible, comment puis-je empêcher les messages ci-dessus d'être spammés dans la fenêtre Debug Output de MSVC 2005? Idéalement, seulement pour cet ensemble particulier de messages?

Answer 1

Généralement, cela est dû au fait que l'application (ou, dans le cas présent, une bibliothèque liée) se charge et se charge dynamiquement via LoadLibrary [Ex] etc. Il est probablement également en train de créer/détruire un thread.

Je ne connais aucun moyen de supprimer les messages de sortie de débogage individuels. Vous pouvez peut-être empêcher le chargement/déchargement répété spécifique en chargeant la bibliothèque vous-même et en tenant une poignée pour la durée des appels (ce qui devrait empêcher le système d'exploitation de le décharger). Cependant, ceci n'est pas une bonne solution générale (par exemple, la bibliothèque pourrait être [mal codée] pour compter sur la DLL non initialisée entre chaque appel, auquel cas la solution de contournement pourrait modifier le comportement). À un niveau supérieur, le maintien d'une connexion ouverte à la base de données peut accomplir la même chose, mais cela dépend de l'implémentation de la bibliothèque cliente SQL native. C'est ce que j'essaierais probablement, (ou simplement ignorer la sortie de trace de débogage).