ODBC de MARS mais ADO/OLEDB de VENUS?

Question

Courte question: Je trouve que j'ai besoin d'utiliser MARS sur ODBC mais pas sur ADO/OLEDB, est-ce correct?

explication plus longue:

Je viens de découvrir mon code ODBC (en utilisant "Driver = {SQL Native Client}", MFC Code CDatabase) doit avoir MARS ("MARS_Connection = yes;") parce que, bien que je ne pas émettre plusieurs SELECT lors de l'ouverture d'un RecordSet, je récupère un lot de lignes, puis j'ai besoin d'ouvrir un autre RecordSet pour émettre un nouveau SELECT, puis de revenir au premier RecordSet pour le lot suivant. Sans le MARS je reçois une erreur ODBC "La connexion est occupée avec les résultats pour une autre commande". Tout va assez bien.

Toutefois, mon code fonctionne de manière identique avec ADO/OLEDB ("Provider = SQLNCLI", #import msado15.dll) au lieu de ODBC. Dans la même situation, j'ai pas a dû spécifier "MarsConn = oui".

Je suis confus/surpris. Est-ce correct/prévu, ou ai-je oublié quelque chose?

Answer 1

Si quelqu'un est intéressé, j'ai découvert quel est le problème/la différence. J'ai dû revoir le code à cause d'un problème subtil dans l'affaire ADO, qui s'est avéré être lié.

Si vous avez besoin de plusieurs RecordSets simultanés, c'est facile avec ODBC, car si vous n'utilisez pas MARS il n'y a que des erreurs, comme ci-dessus.

Avec ADO/OLEDB, cependant, c'est plus subtil. Lorsque je n'utilise pas MARS, plusieurs RecordSets semblent fonctionner correctement. Mais, sous les couvertures, ce qui se passe est que ADO ouvre automatiquement une nouvelle session pour chacun, mais vous ne savez pas à ce sujet et ne pouvez pas le dire. Et cela s'avère très lent, car chaque session nécessite une ouverture de session complète d'audit, et je crée, ferme et recréer tout le temps. Donc, je mets en "MARS Connection = True" pour ADO et, maintenant &, il se comporte maintenant comme ODBC, en réutilisant la connexion existante au lieu d'en créer de nouveaux.

Ainsi, la morale est la suivante: vous doivent avoir MARS pour ODBC, tandis que ADO/OLEDB va permettre à plusieurs RecordSets simultanées sans MARS en faisant sa propre chose, mais il peut (bien) ne pas être ce que vous voulez/est le meilleur .