Имеем связь Fox MySQL. И все бы было хорошо, но у хостера нельзя поменять параметр wait_timeout равный 60 секундам. Отсюда постоянные разрывы. Если для запросов передаваемых на сервер можно сделать реконнект, то как быть с Remoteview? Я так понимаю каждый RV создает свой коннект с базой и номер его нам не известен. Перезагружать каждый раз при ошибке?

Specifying connection attempt timeout

Димон71
то как быть с Remoteview? Я так понимаю каждый RV создает свой коннект с базой и номер его нам не известен. Перезагружать каждый раз при ошибке?

Во-первых уже 2 версии (и > 10 лет) как существуют cursoradapter с гораздо более гибкими возможностями по управлению "коннекцией" чем было у RV.
Во-вторых RV далеко не всегда создаёт "по коннекции" на каждый свой экземпляр (на каждый курсор). Ну по крайней мере если разработчик более-менее адекватен, и это таки основное хранилище данных для программы, а не 2-3 "левых" таблички для загрузки/выгрузки информации для другой системы...
Он, при использовании флажка shared connection, только одно соединение устанавливает (для заданного объекта connection в dbc - если connection разные, то и соединения, конечно, будут отдельные), и через него и работает. Получить сам хендл несложно - он виден через CursorGetProp("ConnectHandle"). Учти только что с 7-й версии фокса есть 2 отдельных понятия: connection handle (который по большому счёту в фоксе не виден) и statement handle (которым как раз и манипулируют все SQL* функции).
Кроме того в крайней версии фокса есть и функция ASQLHANDLES() которая собирает ВСЕ хендлы (именно statement) - либо для всех соединений, либо для того, чей statement handle передан в качестве 2-го параметра.
Вкупе с функцией SQLIDLEDISCONNECT() это позволяет более-менее "автоматизированно" восстанавливать разорвавшиеся по таймауту, или иным причинам соединения.
Смысл SQLIDLEDISCONNECT в том, что она переводит указанный хендл в особое "псевдо-отключенное" состояние, в т.ч. и "поломанный" хендл. И, что самое приятное, фокс автоматом пытается "восстановить соедиенние" когда кто либо попробует работать с этим "псевдо-отключенным" хендом. В т.ч. и RV.
Конечно, там есть масса всяких тонкостей/нюансов, особенное если соединение нужно "донастраивать" после установления (ну там пару каких set-подобных команд заслать, или какие записи в "служебных" табличках завести), но в принципе задача решаема.
Поищи по форуму про SQLIDLEDISCONNECT - потом уж более предметно вопросы задавай.

P.S. И не слушай "вредителей", советующих гадости типа каждые 30 секунд "пустую" команду слать, чтобы соединение поддерживать в активном состоянии. Это отвратительное решение, к тому же половинчатое - от других причин "разрывов" (кроме серверного "таймаута неактивности") оно не спасает никак.





Исправлено 1 раз(а). Последнее : Igor Korolyov, 22.12.17 13:23

Спасибо.

Посмотрел, что действительно каждому RV создавалось свое соединение. Применение параметра Share повесило их всех на одну сессию. Отлавливать ее дисконнект теперь не составит труда.

Учти что просто так их нельзя вешать на 1 соединение - нужно донастраивать RV - либо вручную поочерёдно открывать и следить что "всё вынулось, коннекция свободна" (т.е. как минимум отказаться от DataEnvironment и дописать код для опроса свойства ConnectBusy для соединения), либо FetchSize выставить в -1 (на уровне системы), чтобы отключить "прогрессивную" выборку. Иначе неизбежны проблемы при одновременном открытии нескольких таких курсоров, и наличии хотя бы в одном из них >100 записей.
Ну и да, на самом деле и "отлавливать разрыв" и тем более всё восстанавливать это не так уж и просто как может показаться на первый взгляд... Очень сильно зависит от принятой системы обработки ошибок, ну и от метода использования RV - при помещении их в DE форм и "автооткрытии" ну очень непросто отследить на каком этапе и что там "сломалось"...