Мне говорят, что сразу закрыть приложение.
Может, это самое простое и правильно?
Работаем с MySQL

Тут 2 вопроса

1. Валится сам VPN

2. Валится коннект к БД

Если п. 2, то использовать SQLIDLDISCONNECT()

Ydin
Может, это самое простое и правильно?

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

2. Валится коннект к БД
А какой код ошибки для распознания?
Писал не я, а стоит код

И, похоже, не срабатывает
1526 - ODBC error

Цитата:

использовать SQLIDLDISCONNECT()

А подробней можно. Я это все слабо знаю



Исправлено 2 раз(а). Последнее : Ydin, 24.03.17 11:59

Мои эксперименты, 13 лет назад, нифига себе

forum.foxclub.ru

Ydin
2. Валится коннект к БД
А какой код ошибки для распознания?

Сэмулируй разные варианты "разрыва" и посмотри. Это всё от драйвера зависит чего и как он пишет - общая то ошибка будет 1526...
Проверь как минимум:
- разрыв VPN.
- убиение коннекта на самом сервере разными способами - и если явно кикнули юзера, и перезагрузка экземпляра БД.
Думаю там разные "уточняющие коды" будут.

Ydin

Цитата:

использовать SQLIDLDISCONNECT()

А подробней можно. Я это все слабо знаю

Эта функция разрывает соединение, но оставляет хендл "живым" при том фокс не забывает параметры этого соединения, и АВТОМАТИЧЕСКИ его восстанавливает (ну, точнее пытается восстановить) при обращении SQL* функций к этому хендлу.
Как раз в случае "разрывов" это позволяет не убивая всё то что было получено через соответствующий хендл (SPT курсоры, курсор-адаптерные курсоры, наверное даже RemoteView курсоры) попробовать вернуть их к жизни. Все эти объекты внутри себя хранят хендл, и подсунуть "новый, восстановленный" можно лишь курсор-адаптеру, для других курсоров он ReadOnly. А SQLIDLDISCONNECT позволяет более/менее корректно закрыть соединение, а потом для ТОГО ЖЕ хендла (т.е. грубо говоря для того же "числа") создать новое соединение.
Из явных минусов - если соединение дополнительно настраивается (т.е. перед работой нужно какие-то команды выполнить) то надо повторить все эти команды после "восстановления связи". Если вдруг используются какие-то идентификаторы серверного процесса/сессии, то они будут уже другие (т.к. это реально новая сессия будет).
Само "восстановление" лучше делать в цикле в обработчике ошибок - не просто SQLIDLDISCONNECT() + retry той команды/функции что свалилась. С возможностью таки всё остановить и выйти - т.к. не факт что удастся "починить" связь.

Ну и да, самый "простой" вариант обработки таких ошибок это просто корректно закрыть всю программу Но он очень уж недружественный к пользователю. Даже если предусмотреть сохранение "не сохранённых из-за разрыва данных" в какой-то локальный файл - dbf/xml или ещё что...

Павел и Игорь, спасибо!
Информацию дали хорошую и очень быстро.

Igor Korolyov
Сэмулируй разные варианты "разрыва" и посмотри

Я сижу дома. Через VPN подключаюсь к серверу, что на работе.
Там запускаю приложение, а перед этим через VPN подключаюсь к БД, если его еще не было.
И это реальная БД заказчика, на кот. не "вытащишь шнур". И как эмулировать не представляю.
А надо, иначе ничего не сделаю!
Как то программно?



Исправлено 1 раз(а). Последнее : Ydin, 24.03.17 13:17

Коннектюсь, потом отключаю Vpn-подключение - не отключает!
Вышел из программы, все равно не отключает. Может кто-то из наших работает.
Без шнура плохо.

Ydin
Павел и Игорь, спасибо!
Информацию дали хорошую и очень быстро.

Igor Korolyov
Сэмулируй разные варианты "разрыва" и посмотри

Я сижу дома. Через VPN подключаюсь к серверу, что на работе.
Там запускаю приложение, а перед этим через VPN подключаюсь к БД, если его еще не было.
И это реальная БД заказчика, на кот. не "вытащишь шнур". И как эмулировать не представляю.
А надо, иначе ничего не сделаю!
Как то программно?

1. Запусти VPN

2. Подключись к БД на "работе" через VPN

3. Сделай kill своему процессу на "сервере на работе" (ну рестартани службу сервера "на работе")

PaulWist
Сделай kill своему процессу на "сервере на работе" (ну рестартани службу сервера "на работе")

Никогда не делал, не знаю как.
Стремно как-то



Исправлено 1 раз(а). Последнее : Ydin, 24.03.17 13:55

"Эмулировать и тестировать" нужно на девелоперской или тестовыой БД, а не на продуктиве
Благо сейчас не проблема установить себе виртуальную машину или даже несколько (MySQL не тяжёлый сервер - полагаю виртуалке с ним вполне достаточно будет 512М памяти и одного ядра - не думаю что у тебя такой уж дохлый компьютер что это будет "невыполнимой задачей") и всё что надо там отлаживать - "не выходя из дому", и, конечно же, не допуская даже малейшей вероятности чего-то испортить в БД заказчика.

Да, согласен. Туплю, однако.
А все-таки как "шнур выдергивать"?
Если дома с ноутом.

В принципе, мне знать код ошибки, дальше ее можно генерировать.
Звонил коллеге, он говорит, правильно

Ydin
aErrorArray(1) = 1526 AND aErrorArray(4) = 'S1T00'

Если никто здесь не знает его, то буду с этим экспериментировать.
У меня есть возможность писать свое в таблицу "Протокол" БД.
Спасибо, с Вашей помощью определился.

Гугл говорит что S1T00 это "таймаут". Полагаю что если принудительно убить сессию на сервере, или перезапустить сам сервер (не разрывая связи с клиентом), то ошибка может быть и другой...
"Шнур выдёргивать" при работе с виртуальной машиной можно - и в VirtualBox и в Hyper-V. А можно просто сетевой адаптер выключать в настройках (работает и с "реальными" машинами)...

Igor Korolyov
VirtualBox и в Hyper-V

Я даже терминов этих не знаю, т.е. что это.
Но мне уже достаточно. По-крайней мере пока. Понял как дальше рулить.
Т.е. как дальше с этим жить. В Инете ничего не нарыл, но Foxclub forever!