Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 >
Av © (2004-01-08 10:25:00)

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

MV (2004-01-13 14:03:00) [1]

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

Av (2004-01-13 13:39:00) [2]

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

MV (2004-01-13 13:06:00) [3]

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

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

Anatoly Podgoretsky (2004-01-13 12:33:00) [4]

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

Desdechado (2004-01-13 12:14:00) [5]

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

Av (2004-01-13 09:30:00) [6]

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

Desdechado (2004-01-12 21:53:00) [7]

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

Av (2004-01-12 14:22:00) [8]

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

Av (2004-01-10 11:48:00) [9]

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

Sergey13 (2004-01-10 09:14:00) [10]

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

Av (2004-01-10 09:08:00) [11]

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

Sergey13 (2004-01-10 08:47:00) [12]

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

Av (2004-01-09 16:22:00) [13]

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

Av (2004-01-09 16:20:00) [14]

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

Desdechado (2004-01-09 15:57:00) [15]

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

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

Av (2004-01-09 13:58:00) [16]

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

Av (2004-01-09 13:34:00) [17]

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

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

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

AV (2004-01-09 09:34:00) [19]

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

MV (2004-01-08 16:45:00) [20]

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

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

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

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »