Как сделать автообновление записей. (Clipper-DBF на Apollo6)

← →
Av (2004-01-08 10:25) [0]

Такая проблема...Несколько пользователей по сети используют одну таблицу (Clipper-DBF на Apollo6), как сделать автообновление записей, чтобы при изменении записи эти изменения были видны и у других пользователей. В данный момент изменения видны только после прокрутки Grida, что не есть хорошо. AutoRefresh установлен в True. Если есть какие то решения, мысли или обрывки мыслей, прошу поделиться. Заранее спасибо.

← →
Sergey13 (2004-01-08 10:47) [1]

2Av (08.01.04 10:25)
>В данный момент изменения видны только после прокрутки Grida
Т.е. пока не прокрутишь до нужной записи, ее не видно? Это и правда не нормально. 8-)

А как бы ты хотел то?

>Если есть какие то решения, мысли или обрывки мыслей, прошу поделиться.
Делюсь "обрывками". Брось ты это... 8-)

← →
Av (2004-01-08 11:09) [2]

В том то и дело, что не до нужной записи. Добиться обновления можно только прокруткой Grida до тех пор, пока запись не уйдет за границу этого самого Grida, а потом уже возвращается обновленной. Вот такая беда.

← →
Sergey13 (2004-01-08 11:35) [3]

Ну дык там наверное при перерисовке грида данные перечитываются заново. Apoll6 - это что, я не в курсе, компоненты доступа? Может они так и работают. В общем случае, для того что бы увидеть "чужие" изменения надо переоткрыть датасет.

← →
VAleksey (2004-01-08 11:42) [4]

Такие "проблемы" должны решаться обдумыванием того, как это сделано и почему сделано именно так.

← →
Ильш (2004-01-08 11:54) [5]

При многопользовательском доступе такая проблема всегда возникает. Решение может быть таким: надо как-то контролировать изменения в базе и сообщать всем пользователям об этом и делать рефреш. Вот тока реализация???? Биг проблеммм...

← →
Desdechado (2004-01-08 12:38) [6]

работа по сети и табличный доступ - это немного ненормально :)
пользуйся ApolloQuery и отбирай только те записи, которые нужны. А для обновления отдельную кнопку прилепи - это общепринятый прием.

← →
Av (2004-01-08 13:54) [7]

Спасибо, буду ковырять. С кнопкой не прокатит.

← →
VAleksey (2004-01-08 16:18) [8]

> Desdechado © (08.01.04 12:38) [6]

Любое Query для локальных таблиц все равно вытянет ее всю.

> Av (08.01.04 13:54) [7]

Только с кнопкой и прокатит. Иначе - никак.

← →
MV (2004-01-08 16:45) [9]

Спасибо, буду ковырять. С кнопкой не прокатит.

Еще один бедняга...

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

Если для контроля изменений - то можно формировать сервер приложений, генерирующий события для клиентов, с указанием, что и как изменилось. Лови их и отображай. Ручками. Господи, какой гемор...

← →
AV (2004-01-09 09:34) [10]

Да...гемор полный..все больше склоняюсь к кнопке.

← →
Строитель (2004-01-09 11:35) [11]

Создай дополнительную таблицу "Синхронизация". В нее поля: "Имя таблицы", "Номер записи" (или имя ключа) и "Счетчик". При подсоединении к базе данных читаешь из "Синхронизация" максимальное значение "Счетчик" и сохраняешь во ВнутреннейПеременной.
При записи данных в любую таблицу БД (у какого-то пользователя), в той же транзакции, пишешь информацию об этой записи в таблицу "Синхронизация".
По таймеру (раз в 5-10 сек) (у всех пользователей) делаешь выборку из таблицы "Синхронизация" с условием (Счетчик > ВнутренняяПеременная). Таким образом получаешь имя таблицы, в которой обновилась запись, и, непосредственно, номер обновленной записи. Обновляешь ее (запись, а не всю таблицу), а потом обновляешь значение ВнутреннейПеременной на новое значение. Причем это все делать можно в основном потоке, потому как запросы на обновление выбирают только одну строку из таблиц, поэтому выполняются быстро и незаметно для пользователя.

← →
Av (2004-01-09 13:34) [12]

Спасибо, это вариант...хотя не хотелось блудить лишних таблиц. Надо попробовать...кнопка вообще не катит.

← →
Av (2004-01-09 13:58) [13]

>Строитель (09.01.04 11:35) [11]
А если за 5-10 сек, эти самые пользователи успеют добавить, предположим 3-4 записи, то тогда нужно будет обновлять все эти записи...так? В цикле. А будет ли это незаметно ? Или нужно уменьшать таймер до 1-2 сек, чтобы не успели добавить, хотя по теории вероятности найдется несколько пользователей, которые нажмут кнопку добавления практически одновременно и опять же добавится несколько записей. Подозреваю, что уменьшение таймера приведет к тому, что пользователи будут замечать обновление записей. Или я ошибаюсь? Самый лучший способ проверить это на практике.

← →
Desdechado (2004-01-09 15:57) [14]

2 VAleksey © (08.01.04 16:18)
написано же - "отбирай только те записи, которые нужны"

2 AV
замечено, что такое обновление, когда пользователь не хочет - сначала радует, потом нервирует, а потом и раздражает, особенно когда юзер не может в этот момент сделать срочно то, что он начал, но еще не сохранил

← →
Av (2004-01-09 16:20) [15]

> Desdechado © (09.01.04 15:57) [14]
Да. База синхронизации, это конечно интересно. Установил я таймер на 5 сек, обновлял запись, и через каждые 5 сек грид центровал эту обновленную запись по центру грида, т.е. визуально она терялась, от этого конечно то же можно избавиться, но уже слишком много проблем (решая одну, сталкиваешься с другой)...плюну я на эту затею.

← →
Av (2004-01-09 16:22) [16]

Обновление всего одной записи по таймеру уже убивает, а на нее еще надо перейти....блин.

← →
Sergey13 (2004-01-10 08:47) [17]

2Av (09.01.04 16:22) [16]
Что и требовалось доказать. 8-)
Просто перед автоматизацией обновлений надо ответить себе на вопрос: "Неужели ВСЕ пользователи ОДНОВРЕМЕННО работают С ОДНОЙ(ними) и той-же записью(ями)?". Если ответ - НЕТ(а он такой по жизни в 99.9% задач), то НАФИГА обновлять то, что пользователю СЕЙЧАС не нужно?

← →
Av (2004-01-10 09:08) [18]

Вот к такому же выводу мы и пришли, правда могут быть небольшие косяки ввиду специфики задачи, но это действительно только на 99,9%. Поставим кнопку, а может и вообще без нее, разберемся.

← →
Sergey13 (2004-01-10 09:14) [19]

2Av (10.01.04 09:08) [18]
>Вот к такому же выводу мы и пришли, правда могут быть небольшие косяки ввиду специфики задачи
Эти косяки исчезнут на 100% если вы перейдете на нормальный БД-сервер. Если уж пошла работа по сети - то переход на SQL становится жизненно необходимым.

← →
Av (2004-01-10 11:48) [20]

Беда....файл сервер и задачи под Дос,базы Clipper, многоползовательский доступ, вот в этом и приходиться ковыряться.

← →
Av (2004-01-12 14:22) [21]

Может еще у кого какие мысли есть?

← →
Desdechado (2004-01-12 21:53) [22]

При многопользовательском доступе DBF - очень тяжко. Переходите на SQL-сервер.

← →
Av (2004-01-13 09:30) [23]

Да, конечно, но очень много задач под досом и сразу на sql перейти не получиться.

← →
Desdechado (2004-01-13 12:14) [24]

естественно.
Но, как говорится, иногда надо сломать картонный дом и построить каменный, чем латать картонных, которых все равно завалится скоро сам.
Постепенно переходить, позадачно. Пускай они даже к нескольким БД при этом будут цепляться (к DBF и SQL одновременно) - временно.
Если же БД одна, а задач много, то сначала переходи на SQL-запросы в новых программах. А потом просто конвертнешь DBF в SQL-сервер и все.

← →
Anatoly Podgoretsky (2004-01-13 12:33) [25]

Av (09.01.04 16:20) [15]
Правильно, поскольку эта затея из дурдома, кроме особыз приложений.

← →
MV (2004-01-13 13:06) [26]

Делал я авто-обновление... Мрак и гемор. Потом убирал.
Пример: шеф отвлекся, глядя на ноги секретарши, настроение улучшилось, он забыл, чем занимался, потом встрепенулся, перевел взгляд на монитор - а там - фиг. И "программера - ко мне!"

На SQL переходить НУЖНО. Я раньше МНОГО программил под FOXPRO и CLIPPER. Когда перешел на SQL, понял, "сколько дней потеряно".
Кстати, обратно зовут, платить много предлагают (сопровождать некому). Ни за что.
А миграция обычно очень проста.

← →
Av (2004-01-13 13:39) [27]

Во...вот теперь становится интереснее, а если не сложно, может быть в общих чертах посоветуете с чего начинать и чем кончать ...чтобы шишек на своем опухшем лбу поменьше набивать. И опять же "дней потерянных" не считать. Таких проблем мало. Любой совет ценен. Спасибо.

← →
MV (2004-01-13 14:03) [28]

Ну, наверное, самый простой способ: ревес - инжиниринг. Грузишь, например, в ErWin структуру всех таблиц FoxPro своей базы (здесь база - это не одна таблица, а совокупность всех таблиц приложения). Потом задаешь в качестве TargetServer - InterBase, и меняешь типы данных FoxPro на подходящие типы InterBase.
Определяешь констрейнты, индексы, ключи.
Генеришь базу. Пишешь прогу по перекачке данных. (Или DataPump из Delphi юзаешь).
Остальное все - ручками.

Как сделать автообновление записей. (Clipper-DBF на Apollo6) Найти похожие ветки