Просто продолжение этого вопроса ... с частичным решением.
Я запустил трассировку, на самом деле их было много. Что я обнаружил, так это то, что существует множество причин для этих ошибок. Я смог найти и исправить один из них, но мы все еще получаем эту ошибку в других местах, и они не отображаются на следах, которые я сделал.
Так в чем же заключалась сделка с той, которую я нашел? Ну, из трассировки я обнаружил, что эти ошибки 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. У нас раньше были проблемы с этим типом вещей, так что это может быть причиной проблемы ... но свидетельство в пользу того, что причиной является дополнительный столбец идентификации,