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

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

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

Многопользовательский доступ к dbf из программ на Delphi [D5, dBase, FoxPro]

F... © (2003-10-27 05:46:00)

Мне нужно к базе данных в формате dbf обращаться с нескольких рабочих мест (с разных компьютеров) из приложения написанного в Delphi. Прекрасно понимаю, что проще сделать на каком-нибудь SQL сервере (IB/FB, MySQL, и т.д.), но таково требование!
И так, как сделать многопользовательский доступ к dbf в приложениях написанных в Delphi? Какие настройки? Какие тонкие места? Что можно почитать на эту тему (укажите пожалуйста ссылки)?

F... (2003-10-31 09:13:00) [1]

> 1. DBF, разумеется, будут находиться на сервере.
Да!

> 2. Почему "никакой 3-хзвенки" ? Кто и на основании чего
> внес это ограничение ?
Требование заказчика! К сожалению обсуждению этот пункт не подвергается!

> 3. Про SQL-сервер и речи не идет.
Точно! см. ответ на предыдущий вопрос!

> 4. "И только DBF" + программа, выполняющая роль AppServer"а,
> на той же машине, где и те самые DBF .. что здесь противоречит
> условиям ? Кто-что тебя ограничивает в создании AppServer"а ?
Мы то за, а вот япония против... (из известного анекдота)

Digitman (2003-10-31 08:29:00) [2]

> А требование таково: необходимо написать программу, которая
> будет обращаться к dbf находящиеся на сервере! То есть никакой
> трёхзвенки, никакого SQL сервера! И только DBF!

1. DBF, разумеется, будут находиться на сервере.
2. Почему "никакой 3-хзвенки" ? Кто и на основании чего внес это ограничение ?
3. Про SQL-сервер и речи не идет.
4. "И только DBF" + программа, выполняющая роль AppServer"а, на той же машине, где и те самые DBF .. что здесь противоречит условиям ? Кто-что тебя ограничивает в создании AppServer"а ?

F... (2003-10-31 03:53:00) [3]

Неа нету! В тестовой базе только одна таблица с двумя полями и 1000 записями (без индексов).

Anatoly Podgoretsky (2003-10-30 12:21:00) [4]

У тебя индексы есть, если есть то они обновляются в монопольном режиме, все остальные ждут

F... (2003-10-30 12:02:00) [5]

И всё таки я не получил ответ на вопрос: Почему При подключении новых пользователей (с других машин) скорость работы резко ухудшается (в десятки раз, см. выше результаты 2х экспериментов)?

F... (2003-10-30 05:26:00) [6]

В своём вопросе я писал:
...Прекрасно понимаю, что проще сделать на каком-нибудь SQL сервере (IB/FB, MySQL, и т.д.), но таково требование!

А требование таково: необходимо написать программу, которая будет обращаться к dbf находящиеся на сервере! То есть никакой трёхзвенки, никакого SQL сервера! И только DBF!
Добавлю, что база не большая (около 10 MB) и пользователей пока 3, из них 1 пишуший и 2 читающих!

ЮЮ (2003-10-29 08:56:00) [7]

4. Если записи и так изменяются при помощи SQL не использовать TTable

Anatoly Podgoretsky (2003-10-29 08:53:00) [8]

F... (29.10.03 07:59) [9]
Комментарий простой - запись занята!
Мораль

1. при многопользовательском доступе нельзя на долго занимать запись
2. обрабатывать конфликты, хороши для этого трансакции, см. п. 3
3. перейти на клиент-сервеное приложение, но см. п. 1

Digitman (2003-10-29 08:43:00) [9]

> F...

от твоего фиаско как программера тебя может на время спасти лишь централизация логики обращения к DBF БД на AppServer"е

т.е. дело пахнет "трехзвенкой" : "тонкий" клиент <-> AppServer с DBF-драйвером <-> файл-сервер с DBF-базой

еще лучше, если ф-ции файл-сервера будет выполнять та же машина, на которой работает AppServer - при лок.доступе к таблицам проблемы мультисессионного доступа к ним будут минимальны, да и суммарный сет.траффик будет ощутимо меньше

иначе (при 2-хзвенной архитектуре : "толстый" клиент с DBF-драйвером <-> файл-сервер) рано или поздно неминуемы бесконечные падения индексов и/или нарушения структур DBF-таблиц и/или нарушения ссылочной целостности DBF-базы в целом

F... (2003-10-29 07:59:00) [10]

Интересное дело...
Если на одной машине перейти в режим редактирования в компоненте TTable и выполнять SQL запрос на обновление всех записей, то TQuery без вопросов отрабатывает и изменяет даже ту запись, которая в данный момент редактируется в TTable!
Если же на одной машине перейти в режим редактирования в компоненте TTable, а на другой машине выполнить SQL запрос на обновление всех записей, то TQuery обновит все записи, кроме той которая редактируется с другого рабочего места и в добавок руганётся, что запись занята!

Какие будут комментарии?

F... (2003-10-29 07:08:00) [11]

Что то всё таки не то... Провёл 2 эксперимента со следующими результатами:
1) Запускаю на одной машине 3 тестовых программы. Все настроены на одину и ту же базу, находящуюся на сервере. Время выполнения SQL запроса на обновление (update table1 set field1=1) меньше секунды (около 300 мсек).
2) Запускаю это же тестовое приложение на 2х компьютерах, настройки такие же как в первом эксперименте. При этом время выполнения SQL запроса на обновление чуть больше 15 секунд.
На обоих компьютерах в параметрах BDE установлено LocalShare=True.

Вопрос: В чём проблема?

Anatoly Podgoretsky (2003-10-27 11:30:00) [12]

За взаимное использование баз

F... (2003-10-27 11:28:00) [13]

Я не заметил разнецы (в тестовом приложении) между LocalShare=True и LocalShare=False!
За что отвечает этот параметр?

Anatoly Podgoretsky (2003-10-27 10:03:00) [14]

BDEAdmin

DenK_vrtz (2003-10-27 10:02:00) [15]

BDE Administrator/System/INIT

F... (2003-10-27 09:59:00) [16]

А где эта самая LocalShare находится?
Я нашёл только HandleShared в TDataBase...

kavlad (2003-10-27 09:59:00) [17]

А можно написать свой SQL-сервер :) Или поробывать навоять что-нибудь на midas"е.

Anatoly Podgoretsky (2003-10-27 07:43:00) [18]

Ни каких, но если установишь LocalShare в true, то работать будет более стабильно.

Наверх

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