Потеря соединения ODBC с базой данных SQL Server 2005

Просто выстрел в темноте, но пробовали ли вы запустить трассировку и попытаться зафиксировать события ошибок, а также любой tsql. Это может дать некоторые подсказки или помочь вам увидеть закономерность.

Использование приложения pb и ms sql в качестве базы данных и 2 объектов транзакций, установленных с самого начала. Одна функция проходит через курсор, используя первую транзакцию, и в этом цикле второй объект транзакции используется для обновления другой таблицы. Если явная фиксация не используется после обновления (второй объект транзакции), то первое соединение закрывается, и я получаю сообщение об ошибке [Microsoft] [Драйвер ODBC SQL Server] [DBNETLIB] ConnectionRead (recv()). Как только я вызываю соответствующий оператор фиксации для соответствующей транзакции, все работает как по маслу. И ДА, ошибка всегда находится где-то перед тем местом, где вы фактически получаете сбой, при условии, что вы находитесь в режиме отладки. Интересно, что Sybase удалось закрыть/открыть соответствующую транзакцию без необходимости явно выполнять фиксацию для второго объекта транзакции!!!!

Просто продолжение этого вопроса... с частичным решением.

Я провел трассировку, точнее, несколько из них. Что я обнаружил, так это то, что причин этих ошибок может быть несколько. Мне удалось найти и исправить одну из них, но мы все еще получаем эту ошибку в других местах, и они не отображаются на трассировках, которые я сделал.

Так в чем же дело с тем, что я нашел? Что ж, из трассировки я обнаружил, что эти ошибки ODBC появились после другой ошибки 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.

Из кода FoxPro я обнаружил, что оператор вставки вызывает эту ошибку... не всегда... но иногда. В этой вставке они тянули все поля из одной таблицы, а часть полей из другой таблицы - в третью таблицу. Каждая таблица в этой базе данных имеет столбец идентификации с именем id_col, а оператор select, который заполнял третью таблицу, возвращал два поля id_col.

insert into tablethree 
select a.*, b.price, b.item, id_col 
from tableone a, tabletwo b 
where a.item = ....

Когда мы реструктурировали код так, чтобы возвращался только один id_col... ошибки прекратились.

Честно говоря, есть еще одна возможная причина этой ошибки, которую я исправил одновременно. Прямо перед этим был еще один большой/длинный запрос, в котором использовался синтаксис Foxpro Rushmore (например, a.item+a.customer = lc_item+lc_customer) в запросе сервера sql. У нас были проблемы с этим типом вещей раньше, так что это может быть причиной проблемы ... но доказательства очень сильно свидетельствуют в пользу того, что причиной является дополнительный столбец идентификации.

Не уверен, что вы нашли полное решение, но проверяли, прерывается ли когда-нибудь сетевое соединение? Одна из программ VFP, которую я разрабатывал, начала очень часто терять SQL-соединение для пользователей, которые использовали ноутбуки. Казалось, что ноутбуки временно теряют сетевое соединение. Даже если соединение пропало всего на пару секунд, дескриптор в VFP необходимо сбросить. Не уверен, что это именно ваша проблема, но звучало похоже на меня.