Здравствуйте, уважаемые коллеги!
Ситуация такова:
У клиента MS SQL Server 2016 (недавно - раньше был 2008). Интерфейс - VFP 9.0 SP2 В строке подключения имя ODBC драйвера не изменялось (как было, так и осталось SQL Driver).
VFP приложение ведет лог ошибок.
В приложении предусмотрено автоматическое переподключение к БД при разрыве соединения (3 попытки с таймаутом 30 сек).

Где-то с неделю назад в логе стало регистрироваться намного больше, чем обычно, попыток реконнекта. Большинство из них успешные, но есть и неуспешные. Намного больше - это значит, что раньше это был один - два случая раз в 1-2 месяца, а сейчас - около 100 случаев за сутки.

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

Единственное, что я могу пока посоветовать клиенту - это увеличить количество попыток реконнекта и величину таймаута.
Как влияет используемый драйвер ODBC в данной ситуации - честно - не знаю. Но до сих пор такой проблемы не было, она возникла внезапно.

Особенно смущает то, что проблемы связи с сервером выражаются не только в потере/восстановлении коннекта, но и в ошибке 1190 (размер курсора превысил 2Гб). Ошибка почему-то регистрируется, в основном (но не только - 95% случаев), для одного и того же view. View, участвующие таблицы и запуск в SQL менеджере - всё выглядит очень пристойно, ничего настораживающего.

Не было ли у кого-нибудь чего-нибудь похожего? Нет ли каких-нибудь средств диагностики? Нет ли у кого-нибудь опыта использования трейсинга ODBC - стоит ли с ним связываться?

ou
Особенно смущает то, что проблемы связи с сервером выражаются не только в потере/восстановлении коннекта, но и в ошибке 1190 (размер курсора превысил 2Гб). Ошибка почему-то регистрируется, в основном (но не только - 95% случаев), для одного и того же view. View, участвующие таблицы и запуск в SQL менеджере - всё выглядит очень пристойно, ничего настораживающего.

И что конкретно проверялось? ЧТО выглядит пристойно? Курсор на 2 Гига - далеко не пристойно.

ssa
И что конкретно проверялось? ЧТО выглядит пристойно? Курсор на 2 Гига - далеко не пристойно.

Это однозначно.
Я имею в виду, что мне ни разу не удалось получить хоть какую-то ошибку, выполняя вручную в SQL менеджере запросы, аналогичные тем, которые посылает VFP. Это примитивный select * from .... for param1=val1. Сама таблица - не супербольшая - несколько десятков тысяч записей, да и не селектятся они все сразу никогда. Вся таблица заведомо меньше 2Гб.

При тестировании приложения у меня такая ошибка тоже никогда не случалась.

Еще раз - так что же проверялось. И как?

Проверялась принципиальная выполняемость запроса (в SQL менеджере).
Проверялась выполняемость запроса в приложении (тестировались функции приложения, в которых выдается этот запрос).

Многократно, в цикле.

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

Конкретика, наконец-то будет? Или только абстрактные рассуждения про коней в вакууме? Вы техническим спецам предлагаете лечить ваш софт по вашим описаниям?

К сожалению, более конкретной конкретики, чем описана в первом посте у меня нет.

Запрос вида
select * from view1 where par1 = val1
для таблицы, полный размер который намного меньше 2Гб, в некоторых случаях (для разных пользователей) завершается с ошибкой 1190.
Запрос синхронный, курсор не наращивается в цикле, а создается однократно.
Одновременно с этой проблемой в логе приложения зарегистрированы многократные переподключения к БД, но не для тех пользователей, у которых возникла ошибка 1190.

Проблема возникла "на пустом месте", изменений в приложении не было. Мне лично для себя неплохо было бы понять, не может ли это быть проблемой совместимости версий ODBC драйвера и MS SQL сервера, но я не вижу способа, как этого добиться. И может ли вообще быть такая проблема.

А Вы не могли бы намекнуть, какая конкретно более конкретная конкретика могла бы сделать ситуацию более понятной?

Вы опять повторили все то, что уже написали. Зачем?
Где технический данные, а не ваши пересказы? Количество записей не примерно, а точно? Размер записи?
На какой строке программы вылетает ошибка? Откуда уверенность, что ошибка выскакивает именно из-за этого запроса?
Где доказательства ваших слов? Где технические сведения, а не ваша интерпретация этих сведений?

Вообще то давно уже стоит использовать для соединения драйвера из состава Native Client.
Насколько я в курсе, ни один ODBC из драйверов для MSSQL не называется штатно "SQL Driver".
Это либо "SQL Server" для мега-старого драйвера из поставки ещё 98 винды, либо "SQL Server Native Client xx.0" - где xx номер версии - крайняя вроде бы 13-я, для 2016 версии сервера.
Возможно, конечно, что проблему можно решить какими-то "настройками совместимости" на сервере (старый драйвер не понимает в частности новых типов полей), но я бы в любом случае перешёл на использование свежих версий ODBC драйверов...
Ну и как всегда - если ранее всё работало как положено, клиент (фоксовая программа) не менялся, а сервер поменялся, то, очевидно, проблема лежит именно в области сервера или средств доступа к нему (ODBC). В фоксовой программе, конечно, можно попытаться какие-то костыли повставлять, но это не совсем правильный путь решения проблемы...

Igor Korolyov
Это либо "SQL Server" для мега-старого драйвера из поставки ещё 98 винды, либо "SQL Server Native Client xx.0" - где xx номер версии - крайняя вроде бы 13-я, для 2016 версии сервера.

Да, спасибо, SQL Server, конечно. Не исключено, что именно тот самый старый и есть.
Я на ВМ клиента, на которой, установлен VFP, сейчас использую в строке подключения именно 13 версию. Буду стараться убедить клиента попробовать ее в рабочем режиме.
Вы помогли мне принять решение проявить больше настойчивости в этом вопросе

раз речь зашла про disconnect то мона глянуть и параметр AutoClose
ну мало ли

Что в строке подключения - ip адрес или DNS имя сервера, если DNS то проблема в сети и надо для начала попинговать сервер.

Да, ещё неплохо было бы увидеть код (или хотя бы предметное описание использованного метода) "переподключения при обрыве". Используется ли SQLIDLEDISCONNECT() с последующим "автовосстановлением", или как-то "вручную" закрываются старые хендлы и открываются новые (но что тогда происходит с курсорами полученными через старые соединения). Используются ли курсорадаптеры, или всё абсолютно "вручную" кодится. Используется ли общее "глобальное" соединение на всю программу, или несколько отдельных, или хотя бы хендлы "дочерние" полученные через SQLCONNECT(базовый_хендл) для "разделяемого" aka Shared соединения.
Это всё параметры/нюансы которыми можно "поиграться" - возможно будет найдено если и не решение, то хотя бы рабочий "костыль".
скажем у нас с ораклом была интересная проблема - на некоторых машинах ("шаблон" выявить не удалось - вероятно это целый комплекс факторов - сочетание версий ОС, клиентских библиотек оракла, сетевых настроек машин и сопутствующего ПО - типа файерволов/антивирусов/прокси-клиентов - т.к. один и тот же код в других местах работал совершенно без сбоев) при определённой последовательности операций вызывал разрыв соединения - при том "падал" именно серверный процесс - т.е. что-то такое от клиента приходило на сервер, что он умирал (благо не весь сервер, а только процесс связанный с обслуживанием этого одного соединения). Т.к. роковая "последовательность операций" состояла из группы update-ов и последующего insert (ну так из курсорадаптера "позаписно" сохранение шло - сначала изменённые, потом "новые" записи), то "методом тыка" было найдено что если задать для курсорадаптера РАЗНЫЕ хендлы в UpdateCmdDataSource, InsertCmdDataSource ну заодно и в оба оставшихся (для Delete и основной - тот что для Fill/Requery работает) то проблема уходила... Да, убогий костыль, но работает же Хорошо что хватило именно statement хендлов - т.е. не полноценных отдельных соединений. Соединение одно в итоге и осталось...
Так что если хватает сил и желания, то поле для экспериментов тут просто огромное

Добрый день, уважаемые коллеги! Спасибо за отклики.

Foxtrot
параметр AutoClose

Не используется.

PaulWist
Что в строке подключения - ip адрес или DNS имя сервера

IP

Igor Korolyov
неплохо было бы увидеть код (или хотя бы предметное описание использованного метода)

Код, к сожалению, не приведу, потому что его для демонстрации нужно привести в удобочитаемый вид.
Примерно работает так:
В приложении централизованная обработка ошибок и централизованное исполнение SQL-запросов.
Процедура обработки результата запроса в случае, если произошла ошибка 1526, проверяет жизнеспособность подключения, для чего пытается выполнить [select @@VERSION].
Если этот select отрабатывает нормально, то обработчик считает, что это ошибка, с которой должны разбираться админы, выдает сообщение, пишет в лог и т.д.
Если оказывается, что подключение неживое, то делается несколько попыток подключиться заново. Количество попыток и величина таймаута - это параметры приложения. Если реконнект прошел успешно, то работаем дальше, если нет - сообщение, лог, админ и т.д.
Лог приложения показывает, что успешных реконнектов примерно 95 из 100.
Есть еще обработка фоксовской ошибки 1466 (неправильный SQL-хэндлер), но с этим мне надо еще разобраться - есть подозрение, что там что-то не так работает, как хочется. Но это не главная проблема в текущей истории.

Igor Korolyov
Используется ли общее "глобальное" соединение на всю программу, или несколько отдельных

Соединений три, но одно используется для лога, другое для еще одной побочной цели, так что, фактически для всех остальных запросов - одно общее.

Igor Korolyov
Используется ли SQLIDLEDISCONNECT() с последующим "автовосстановлением", или как-то "вручную" закрываются старые хендлы и открываются новые (но что тогда происходит с курсорами полученными через старые соединения)

SQLIDLEDISCONNECT() не используется. Вручную по описанной выше схеме. Судя по тому, что говорит клиент, старые соединения на сервере остаются.
Как-то мне не приходило в голову, что если в фоксе хэндлер уже не жив, то можно найти от него какие-то остатки. Поищу.
Курсорадаптеры не используются, все управление ручное. Хорошо ли это, плохо ли - не знаю. Работаю в заданных условиях, сопровождая программу, у истоков которой стояли другие люди. Там много уже и мной понаделано ( в частности, вот эта самая обработка ошибок), но "разрушение основ" клиент не допустит. С курсорадаптерами - это ж всё переписывать, а это никому не нужно в программе, которая скоро должна благополучно уйти на пенсию.

Судя по логу есть две группы проблем:
1) Некая проблема коннекта - обработка обработчиком - реконнект. В логе - сообщения 1526 и сообщение о реконнекте.
2) Вот здесь я больше всего не понимаю - то ли это такая реакция на проблему связи, то ли всё же что-то в приложении. Но! Всё же это случается слишком редко по сравнению с общим количеством SQL-запросов:
- ошибка фокса 1190 (файл > 2Гб там, где этого не может быть)
- сообщение 1526
- реконнект
Что здесь причина, что следствие ... Откуда берется это 1190?Может, это результат невозможности обработать какую-то другую ошибку? Но кто не может обработать - фокс или ODBC?
Воспроизвести это искусственно не могу.

Сопутствующие сообщение в логе не особенно информативны. По-моему, мне удалось собрать исчерпывающий список:

Сопутствующие особенности:
1) С тех пор, как была сделана описанная обработка ошибок, этот механизм работал благополучно больше двух лет
2) Проблемы начались внезапно 2 недели назад
3) Стала использоваться другая версия MS SQL сервера, но с этого момента прошло месяца 2, если не больше.

Проблемы с сетью. Ошибка 1190 наведенная.

ssa
Проблемы с сетью. Ошибка 1190 наведенная.

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

И снова здравствуйте, уважаемые коллеги!
После замены драйвера 'SQL Server' на ODBC Driver 13 for SQL Server исчезли фоксовские ошибки 1190.
В остальном картина та же. В логе приложения примерно 100 реконнектов каждый день.
Часто логится ODBC TDS Stream error.
Клиент прочитал в Интернете, что кому-то удалось избавиться от этой ошибки при помощи перехода с ODBC на OLE DB провайдер (правда, в ссылке, которую он мне дал, нет упоминания foxpro - скорей всего, там что-то другое).
Я не вижу в этом смысла, но попробовать надо, хотя бы чисто формально.
Вероятно, это должен быть provider=sqlncli11.

Мне никогда не приходилось работать с OLE DB и поиски не помогли понять, с чего начать. Насколько я понимаю, нужно менять и подключение, и всё общение с SQL-сервером по сравнению с ODBC.
Нужно ли для этого использовать ADODB или что-то другое? Подтолкните, пожалуйста, в нужном направлении.

ou
Часто логится ODBC TDS Stream error.

Это ошибка передачи по сети. OLEDB, как надстройка над ODBC, ничего не изменит.

ssa
Это ошибка передачи по сети. OLEDB, как надстройка над ODBC, ничего не изменит.

Спасибо, я верю. И не вижу в этом смысла (хотя, чем черт не шутит, - может, ole db даст какую-то осмысленную "дообработку" ошибок - если что, я понимаю, что такие мысли в голову приходят от отчаяния ). Тем не менее, мне нужно провести эксперимент, чтобы дать клиенту заключение, подкрепленное практикой.
ODBC попадает под подозрение потому, что клиент утверждает, что сетевые проблемы нигде не регистрируются и web-приложение, работающее с той же базой, таких проблем не испытывает.

Веб приложение работает по той же гнилой сети, или, например, вообще на том же сервере что и СУБД размещено, ну или в одном серверном шкафу
Я не думаю что OLEDB провайдер к MSSQL работает "поверх ODBC" - но то что они работают по одним и тем же сетевым протоколам, а значит будут испытывать схожие проблемы - это более чем вероятно.
В фоксе работать с OLEDB мягко говоря не очень удобно. Да, курсорадаптер имеет определённую поддержку, но всё одно в общем случае это добавление лишних звеньев. Т.к. фокс штатно не работает напрямую с провайдером (были какие-то fll проекты для "прямого" использования интерфейсов OLEDB провайдеров, но чот там вышло в итоге, и где это можно нынче найти - я не могу сказать), а работает именно с ADODB объектами - а они по сути представляют собой "курсорный движок" схожий с фоксовым...
Схема в целом в хелпе описана - создаёшь ADODB.Connection, потом либо создаёшь рекордсеты и подключаешь их к курсорадаптеру, либо позволяешь ему самому эти рекордсеты создавать, для чего создаёшь ADODB.Command и его в CursorFill передаёшь... Потом можно по разному изменения переносить на сервер - либо через начальный рекордсет (для чего он должен быть обновляемым, и с поддержкой закладок - скорее всего "локальным" а не серверным), либо через те же самые отдельные ADODB.Command объекты - где можно, к примеру, вызывать ХП вместо использования "прямых" INSERT/UPDATE/DELETE команд...