forum.clarionlife.net

RaFaeL писал(а): ↑16 Июль 2017, 10:30 Так а может перед каждым GET проверять, не пропало ли соединение?

я не против, но как это сделать в ODBC (mysql) с помощью clarion ? Буду рад подсказке

Admin писал(а): ↑16 Июль 2017, 12:12 Кстати а отдельным тредом нельзя обойтись? Все равно будет виснуть?

Да у меня так и сделано в отдельном треде и зависает все приложение

gopstop2007 писал(а): ↑16 Июль 2017, 10:12

finsoftrz писал(а): ↑16 Июль 2017, 9:56 А еще дополнительно третье приложение, которое следит, не зависло/отвалилось ли второе, чтобы автоматически его снять и перезапустить...

Серьезно, третье? А какие проблемы могут возникнуть, если основное за этим проследит ?

Вполне серьезно. Это зависит от архитектуры и функционала основного приложения.
Как я понимаю, все обычные клиент-серверные приложения предполагают стабильный коннект к серверу. В локальной сети поэтому обычно проблем не возникает. Работа через интернет отличается в этом плане.
У меня задачки несколько иные, но я тоже наступал на подобные грабли. В частности, в конце концов сделал всю работу из удаленной точки продаж с сервером через интернет с помощью отдельного небольшого приложения. Основное вызывает его в виде процесса, передавая параметры командной строки. Если в течении заданного периода времени работа второго приложения не завершилась, то либо прерываем процесс (снимая второе запущенное приложение), либо активируем для пользователя кнопку Прервать. Тут еще есть один важный нюанс. Мы не знаем, на каком этапе произошел сбой соединения. Он может произойти, когда задание на сервере было получено и выполнено, но ответ об успехе от сервера получить не смогли. Например, записываем документ. В этом случае приходится сохранять идентификаторы последнего задания на клиенте и на сервере, а перед очередной операцией с сервером запрашивать и сопоставлять их.
По поводу третьего приложения делал подобное решение, но оно сейчас не в продакшене. Там со стороны веб и мобильных приложений идут запросы к базе данных (tps) на локальном сервере. На сервере крутится небольшое кларионовское приложение, которое эти запросы получает, нумерует, возвращает номер клиенту и выполняет. Клиентские приложения через небольшой интервал времени шлют повторный запрос с номером задания и получают результат. Иногда приложение на сервере отваливается. Причину понять с ходу не удалось. Поэтому приделал сверху небольшое управляющее приложение, которое запускает первое и периодически пингует.

gopstop2007 писал(а): ↑16 Июль 2017, 7:07 Нет не удаляет, как как в этот момент может идти параллельная запись в него данных из основной программы

Какая-такая параллельная запись? Я думал, что этот файл только для синхронизации. Тогда мне не понятен бизнес процесс. Вот у нас, бывает, связь с филиалами рвётся. Мы большие файлы качаем по ftp c докачкой и т.д. Мне представляется так. На одном компе создали файл с данными, послали на сервер. Программа проверила идентичность файла, кинула на сервер пустой файл "OK". На сервере резидентная программа увидела этот пустой файл и начала синхронизацию. Все велосипеды уже изобретены вроде ?

kreator писал(а): ↑16 Июль 2017, 16:57 Какая-такая параллельная запись? Я думал, что этот файл только для синхронизации. Тогда мне не понятен бизнес процесс.

С одним файлом prod.tps может работать несколько пользователей, процесс изменения остатков и записи на сервер быстрее асинхронный .

finsoftrz писал(а): ↑16 Июль 2017, 13:29 Вполне серьезно. Это зависит от архитектуры и функционала основного приложения.
... Основное вызывает его в виде процесса, передавая параметры командной строки. Если в течении заданного периода времени работа второго приложения не завершилась, то либо прерываем процесс (снимая второе запущенное приложение), либо активируем для пользователя кнопку Прервать. Тут еще есть один важный нюанс. Мы не знаем, на каком этапе произошел сбой соединения. Он может произойти, когда задание на сервере было получено и выполнено, но ответ об успехе от сервера получить не смогли.

Спабо за интересную информацию. Интересно как вы контролируйте зависло ли приложение, в процессе работы (отправки, получения данных) или в режиме "ожидания"?

Если запуск второго приложения, которое должно завершиться после выполнения задания, то через процесс. По таймеру проверяем факт завершения процесса.
Если контролируется приложение, которое должно работать постоянно, то запускаем тоже через процесс и пингуем по ip-протоколу. Ответ пришел, значит работает. Не пришел, то зависло или отвалилось. Тогда убиваем процесс и перезапускаем.

gopstop2007 писал(а): ↑17 Июль 2017, 9:04 С одним файлом prod.tps может работать несколько пользователей, процесс изменения остатков и записи на сервер быстрее асинхронный .

В топике было, что файл prod.tps локальный .

finsoftrz писал(а): ↑17 Июль 2017, 17:51 Если запуск второго приложения, которое должно завершиться после выполнения задания, то через процесс. По таймеру проверяем факт завершения процесса.
Если контролируется приложение, которое должно работать постоянно, то запускаем тоже через процесс и пингуем по ip-протоколу. Ответ пришел, значит работает. Не пришел, то зависло или отвалилось. Тогда убиваем процесс и перезапускаем.

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

А что там замысловатого? Запустить прогу не через run, а через функцию win api. Повесить стандартный прогресс по таймеру и проверять, завершила ли прога работу. А обмен сообщениями между приложениями сейчас в с10 стандартный функционал, полключаемый шаблонами...

Вот классик для запуска программы через процесс, может, кому пригодится. Пример вызова:

kreator писал(а): ↑17 Июль 2017, 19:49 В топике было, что файл prod.tps локальный .

Магазин (локально) в котором несколько пользователей(продавец,кладовщик и т.п) и связь с офисом (сервером).

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

Согласен, только начал осваивать И много в ней вещей которые "старые" пользователи не примут, так как привыкли работать с другим интерфейсом

finsoftrz писал(а): ↑18 Июль 2017, 8:14 Вот классик для запуска программы через процесс, может, кому пригодится. Пример вызова:

Огромное спасибо за рабочий пример. Понятно, что есть много примеров по данному вопросу, но когда эти примеры начинаешь использовать(пробовать), вылазит много мелочей, которые сводят работу на нет.

gopstop2007 писал(а): ↑18 Июль 2017, 9:43 Магазин (локально) в котором несколько пользователей(продавец,кладовщик и т.п) и связь с офисом (сервером).

Тогда бы я попробовал сделать так. В локальном магазине периодически запускается некая прога, которая выгружает на удалённый сервер изменения в локальном prod.tps. На сервере при появлении этой выгрузки стартует синхронизация. Повторюсь - чем проще, тем лучше. Проблемы репликации всем известны. Даже в больших SQL с репликацией не всё однозначно.

kreator писал(а): ↑18 Июль 2017, 10:03 Тогда бы я попробовал сделать так...

Я проверяю сейчас такой механизм работы
1. Изменения prod.tps постоянно пишутся в лог prod_log.tps (формат - первое поле инкриминент записи лога id, все поля prod.tps)
2. При отправке на сервер (по таймеру), проверяется последний записанный id (prod_log.tps) с id который записан в файле (last_id.tps)
3. При несовпадении записываем все изменения на сервер из файла prod_log.tps, после отправки всех данных записываем последний успешно записанный id из prod_log.tps в last_id.tps.
4 .. и так по кругу

gopstop2007 писал(а): ↑18 Июль 2017, 9:43

kreator писал(а): ↑17 Июль 2017, 19:49 В топике было, что файл prod.tps локальный .

Магазин (локально) в котором несколько пользователей(продавец,кладовщик и т.п) и связь с офисом (сервером).

У меня сейчас похоже сетка из 14 продуктовых супермаркетов работает. В магазинах 1-2 рабочих места на бэке (Продмаг) и локальная сетка (кассовые узлы, весы). Основная база на сервере через интернет (КупецЪ). Справочники подгружаются с сервера по мере необходимости. Далее работают локально в каждом магазине. По мере готовности документов отправляют их на сервер (утверждают). Либо по одному, либо сразу все неотправленные. Раз в неделю автоматическая принудительная отправка. Если документ надо изменить после отправки, то отправку предварительно отменяют. На сервере документ при этом выключается. При повторной отправке на сервере документ создается заново. Каждую ночь выполняется автоматическая сверка документов и остатков товаров с сервером и по электронной почте отправляется отчет из каждого магазина.
Не просто по сравнению с онлайн доступом к общей базе, зато очень стабильно, устойчиво и быстро. Проблемы со связью, сервером не приводят к останову работы всей сети. База на tps, контакт с сервером через ip-драйвер и серверные функции.
Есть еще одна небольшая непродуктовая сетка. Насколько знаю, 5 магазинов. Там в магазинах просто точки продаж. Справочники также подгружают с сервера. А чеки при пробитии отправляются на сервер. Если сервер не доступен, то автоматически переходят в оффлайн режим. При переходе обратно в онлайн все неотправленные чеки отправляются на сервер. Это гораздо проще, чем на продуктовке, так как все приходы от поставщиков оформляются в центральном офисе.