Вот такую ошибку словил:
Та же база сейчас перепроводится на локалке и с той-же 1С++.dll (2.0.3.5 / Nightly build 2007-09-27 ).
Уже минуло то критичное количество реконнетов на которых был вылет.
Посмотрите плз, что за дела творятся.
Основное отличие: работа в терминале..

А какая <БД по-умолчанию> стоит для пользователя MSSQL (тот что в конфигураторе прописывается), под которым работает эта ИБ 1С?

Да, в принципе не важно какая. Просто бегло анализируя возможные причины описанной ошибки у меня возникло предположение.
Излагаю:
Этот метод как известно закрывает родное соединение 1С и открывает снова.
Дак вот, дело в том, что драйвер ODBC написан так, что вызывая функцию для закрытия соединения, на сервер уходит соответствующая команда, от сервера получается ответ об успешном выполнении этой команды, и функция возвращает управление вызывающему коду. Данное соединение для драйвера ODBC считается закрытым.
НО! Это не означает что сервер к этому моменту уже освободил все ресурсы связанные с этим соединением и собственно удалил процесс связанный с этим соединением.
В результате при выполнении метода ReconnectNative в монопольном режиме, мы можем запросто получить такую ситуацию, что подключаясь снова сразу после завершения соединения, сервер еще не освободит процесс связанный с предыдущим соединением, а так так БД находится в режиме single user он не может создать второе соединеие к этой базе и возвращает описанную ошибку.
Т.е. проблема может быть решена не использованием монопольного режима.

Также есть еще одна особенность драйвера. Сначала соединение всегда устанавливается к БД по-умолчанию, той которая прописана в свойствах пользователя MSSQL. ДАЖЕ в том случае если в строке подключения явно прописана база данных, просто в этом случае драйвер внутренне исполняет инструкцию USE.

На сколько я помню код который я писал в реализации метода ReconnectNative, там инструкция USE какраз исполняется явно (т.е. мной, а не в строке подключения), специально для того, чтобы дождаться освобождения процесса на сервере. При этом, конечно, подключение к БД по-умолчанию должно быть возможно сразу после разрыва соединения.
Т.о. второе решение проблемы - это прописать в БД по-умолчанию базу, которая всегда доступна, например master.

Ну, если это разные БД то эти соединения друг другу мешать не могут, не смотря на то что соединения используют одного пользователя.  
Однако, надеюсь понятно, что в период когда соединение рвется и до того как оно установилось снова может влезть кто угодно(!), различные фоновые задания, или например штатные бекапы базы или журнала транзакций выполняемые агентом, которые вобщем-то обычно часто происходят, и т.п.
Вообще, монопольный режим это зло, особенно в такой задаче с реконнектом.

хотел бы немного уточнить, если можно
в монопольном режиме при использовании ReconnectNative соединение к базе устанавливается "монопольное" или нет?
если память не изменяет то в 2.0.2.2 было не "монопольное".

Еще. Чтобы уже до конца разобраться.
Т.к. эта задача весьма экзотическая, я предвидел такое развитие событий с монопольным режимом, и в методе ReconnectNative есть специальный код, который устанавливает подключение с сервером (с БД по-умолчанию конечно), и дальше, в цикле пытается перевести подключение к текущей БД, пока инструкция USE не выполнится успешно. Т.о. ReconnectNative может ждать освобождения БД бесконечно, пока БД не освободится, другого выхода из цикла не предусмотрено, т.к. в этом случае система останется в неработоспособном состоянии.
Т.е. если в разрыв залез какой-нибудь бекап или другая фоновая задача, она сначала доработает, освободит БД, после этого ReconnectNative продолжит свою работу.

trdm писал(а) 27. Октября 2007 :: 12:15:

Есть же обработка для переноса ТА, или по скорости будет медленее?

DmitrO писал(а) 29. Октября 2007 :: 05:09:

простецкая она для тех, кто разобрался. Я же только представляю себе данные механизмы, но их "изнутри" не счупал.