HELP Проблема при многопользовательском доступе

← →
Alexey K (2004-01-08 15:17) [0]

РАзрабатывалось приложение как локальное DBF (Halcyon). Нужно сделать теперь из него многопользовательское (срок позавчера).
Запустив ее вдвоем с коллегой из сети при вводе данных получили задвоение номеров, и вообче в базе полный мусор при одновременной записи туда. Помогите кто что посоветует как грамотнее блокировать записи или может еще чего нибудь???
С Уважением Алексей К.

← →
Desdechado (2004-01-08 15:28) [1]

при сроке "позавчера" ничего путного не выйдет :(
а по-хорошему:
1. табличный доступ менять на запросный
2. переходить на SQL-сервер

← →
Vlad (2004-01-08 15:34) [2]

Насколько я знаю, в DBF - единственный способ многопользовательской работы - это блокировка записей.
С Halcyon правда не работал, работал из под фокс-про, в качестве счетчика (генератора) ID была отдельная таблица, где при получении нового ID каждый раз блокировалась запись, после чего счетчик инкрементировался и, затем, блокировка снималась.

← →
Anatoly Podgoretsky (2004-01-08 15:37) [3]

Desdechado © (08.01.04 15:28) [1]
Для первого варианта еще придется сменить Halcyon на БДЕ, если это не Фокспро таблицы.

← →
Alexey K (2004-01-08 15:44) [4]

Спасибо конечно, но SQL не пойдет кода очень много не успею я, да и базы то не большие если бы сразу знать... Можно подробнее про генерацию уникальных и блокировку записей. Еще дело в том, что текущий уникальный номер (вернее номер, баз много, млин) сохраняется в ИНИ файле.

← →
unreger (2004-01-09 07:37) [5]

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

Со своей стороны готов поучаствовать в обсуждении.

← →
Sergey13 (2004-01-09 09:52) [6]

2unreger (09.01.04 07:37) [5]
>А никто не хочет реализовать мою давнюю идею - пусть клиенты работают с локальными копиями базы, а синхронизацию дописать самому?
Эта идея напоминает анекдот.
-Вот написал архиватор. Жмет все в 5 байт.
-Здорово!!! Дай поюзать.
-Подожди, вот разархиватор напишу...

← →
Alexey K (2004-01-09 11:10) [7]

Додумал вот до такого варианта.
Сделал таблицу вида
"имя_таблицы" "ID"
"имя_таблицы" "ID"
Уникальные номера берутся из этой таблицы, запись блокируется на и = +1
Запись с полученым ID записывается в нужную таблицу.
Вроде должно работать ? Кто,Что думает, может как то иначе сделать можно лучше, и как уйти от ошибки при блокировке, через try exept?

← →
chudaks (2004-01-09 11:52) [8]

если у тебя делфя 5-я то BDE установлена.
Используй запросы.
Перед тем как ставить новый номер прога должна будет проверить самый последний номер, затем зарезервировать следующий номер.
При редактировании записи проверить не пытается ли кто данную запись редактировать, следовательно нужно поле указывающее редактируется ли запись или нет.

← →
Alexey K (2004-01-09 11:59) [9]

БДЕ никак нельзя, а насчет остального спасибо, меня вот какой вопрос еще интересует, при добавлении несколькими пользователями записей в базу (одновременно) не будет ли ошибок. А вообче спасибо всем ответившим большое! ВзаимоHelp программеров это очень хорошо.

← →
chudaks (2004-01-09 12:03) [10]

можно поступить так:
первоначально хранить все в кэше, затем при записи брать последний номер ID и вписывать туда данные блокируя при этом для остальных базу.

← →
unreger (2004-01-09 12:08) [11]

ну вот опять не оценили идею :)

← →
Alexey K (2004-01-09 12:10) [12]

<kfujlfh. пробовать пора хватит спрашивать.
Должно, млин, получиться.
С благодарностью к Мастерам и создателям сайта . Алексей К.

← →
Alexey K (2004-01-09 12:15) [13]

ДА нет идею оценили, просто сложно и долго это все. Я тоже мечтаю о движке БД с поддержкой DBF или другого простого формата, чтобы везде работала, со встроенным, SQL , поддержкой транзакций, и.т.д MySQL и InterB конечно хорошо но не всегда.

← →
Alexey K (2004-01-09 12:18) [14]

P.S ЗАбыл совсем без БДЕ только, и без установки всяких прочих сервисов , дровов, и.т.д ,,,,а может есть где то что то а?

← →
Academic (2004-01-09 12:18) [15]

unreger (09.01.04 07:37) [5]

Оценил. Кое что уже делал. но проблем много

← →
unreger (2004-01-12 06:49) [16]

>Academic

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

а вообще, надеюсь, что самому мне не придется такое делать :)
но порассуждать - интересно

может подробнее расскажешь о проблемах?

← →
Sergey13 (2004-01-12 09:01) [17]

2Alexey K (09.01.04 12:15) [13]
>Я тоже мечтаю о движке БД с поддержкой DBF или другого простого формата, чтобы везде работала, со встроенным, SQL , поддержкой транзакций, и.т.д
Мечтать не вредно, особенно про транзакции в контексте DBF. Кстати это вроде уже реализовано. Есть какой то сервер (забыл название) который хранит данные в DBF.

>MySQL и InterB конечно хорошо но не всегда.
Зато DBF рулит всегда? 8-) Назови хотя бы пару примеров.

← →
Anatoly Podgoretsky (2004-01-12 09:14) [18]

Alexey K (08.01.04 15:17)
Откажись от хальсиона, поставь БДЕ и уровень таблиц 7, после этого можешь пользоваться автоинкриментными полями, без головной боли с сообственной автонумерацией и блокировками таблицы (от которой столько сможешь получить по голове, что рад не будешь.)

Другой более оптимальный вариант, легкий SQL сервер ИБ и его потомки.

← →
Academic (2004-01-12 12:55) [19]

to unreger
Я пробоват сделать подобное на файлах CDS от TClientDataSet,
Использовал для связи с общей базой MS SQL RemoteDataModule и
TSocketConnection.
Главная беда автоматическое обновление локальных данных.
Есть идея, создавать на клиенте тоже RemoteDataModule, и использовать двунаправленный обмен данными. Т.е. Один пользователь изменил свои локальные данные. Посылаются изменения на сервак. Сервак, используя список доступных RDM клиентов, рассылает обновления. Как? Не слишком мудрено?

← →
unreger (2004-01-12 13:12) [20]

Хорошее слово - оповещения, на каждом клиенте создается таблица изменений (ссылки), а физически клиент обновляет у себя _только_ при необходимости. По-моему - гениально!

← →
Romkin (2004-01-12 13:23) [21]

2Academic дурно это. Зачем именно модуль на клиенте? Северу- серверово... ТЕбе всего лишь извещения от сервера нужны, о том, что данные изменились. А клиент должен сам эти данные обновлять, кода это удобно именно ему.

← →
Academic (2004-01-12 13:54) [22]

to Romkin
И как сервер будет слать обновления клиенту?

← →
Romkin (2004-01-12 14:16) [23]

http://www.rsdn.ru/article/db/callback.xml усе уже сделано :) Можно всем, можно выборочно... Посылаешь не обновление, а извещение, о том, что пора бы обновиться. И клиент, в свободное от основных обязанностей время, обращается к серверу за обновлением сам, явочным порядком.

← →
venoel (2004-01-12 14:22) [24]

А кто-нибудь про Advantage Database Server слыхыл?

← →
Academic (2004-01-12 15:06) [25]

to Romkin
И что клиент делает по этому извещению?
Рефрешит все локальные данные?

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

если запись, которой клиент хочет воспользоваться, есть в таблице изменений, то идет обновление (всей базы или одной таблицы - по желанию :) и из таблицы изменений удаляется

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

← →
Academic (2004-01-13 11:10) [27]

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

← →
unreger (2004-01-13 11:27) [28]

это все хорошо для нормальной клиент-серверной с нуля базы,

а моя идея, что создаем полную локальную копию базы на каждом клиенте и он работает _как и прежде с локальной базой_, время от времени сохраняя свои изменения в эталонной базе,
а локальные дбфки обновляет некий менеджер ... пожалуй для каждой записи в каждой таблице надо добавить поле "было изменено в эталонной базе"...
и как-то перехватывать попытку записи в поле с установленным признаком ...
к автору ветки: а где-нибудь рядом с DBF (Halcyon) триггеры есть?

конечно надо будет разрешать коллизии - несколько клиентов желают отослать все свои изменения в эталонную (ну нельзя это сервером называть) базу - вот есть неплохая идея утроить им чат для этого, с показом конфликтующих данных

HELP Проблема при многопользовательском доступе Найти похожие ветки