ODBC от MARS но ADO / OLEDB от VENUS? - PullRequest
Новая
       42

ODBC от MARS но ADO / OLEDB от VENUS?

7 голосов
/ 18 февраля 2010

Короткий вопрос: Я считаю, что мне нужно использовать MARS поверх ODBC, но не поверх ADO / OLEDB, это правильно?

Более длинное объяснение:

Я только что обнаружил, что мой код ODBC (с использованием «Driver = {SQL Native Client}», код MFC CDatabase) должен иметь MARS («MARS_Connection = yes;»), потому что, хотя я не выдаю несколько SELECT при открытии RecordSet Я получаю пакет строк, затем нужно открыть еще один RecordSet для выдачи нового SELECT, а затем вернуться к первому RecordSet для следующего пакета. Без MARS я получаю ODBC ошибку «Соединение занято с результатами для другой команды». Все достаточно справедливо.

Однако мой код работает одинаково с ADO / OLEDB («Provider = SQLNCLI», #import msado15.dll) вместо ODBC. В той же ситуации я не должен был указать "MarsConn = yes".

Я смущен / удивлен. Это правильно / ожидаемо, или я что-то упустил?

1 Ответ

6 голосов
/ 19 мая 2010

Если кому-то интересно, я выяснил, в чем проблема / разница. Мне пришлось вернуться к коду из-за тонкой проблемы в случае ADO, которая оказалась связанной.

Если вам нужно несколько одновременных наборов записей, это легко сделать с ODBC, потому что если вы не используете MARS, это просто ошибки, как указано выше.

С ADO / OLEDB, однако, это более тонко. Когда я не использую MARS, кажется, что несколько RecordSets работают нормально. Но под прикрытием происходит то, что ADO автоматически открывает еще один новый сеанс для каждого, но вы не знаете об этом и не можете сказать. И это оказывается очень медленным, потому что каждый сеанс требует полного входа и выхода из системы аудита, и я все время создаю, закрываю и заново создаю.

Поэтому я добавил «MARS Connection = True» для ADO, и вот, теперь он ведет себя так же, как ODBC, повторно используя существующее соединение вместо создания новых.

Итак, мораль такова: вам необходимо иметь MARS для ODBC, в то время как ADO / OLEDB будет разрешать несколько одновременных RecordSets без MARS, выполняя свою собственную задачу, но это может (ну) не то, что вы хотите / лучше всего.

...