» Delphi Работа с DBF

вообщим написал приложение для работы с таблицами DBF формата
есть файл настроек dat.ini откуда берется номер компа(участка) и путь к базам и файлу PDOXUSRS.NET
далее при открытии таблицы она вилтруется по номер компа(участка) , тоесть при одновременном открытии несколькими пользователями с разными настройками участков в файле dat.ini каждый будет видить только свои записи.

вопрос!

все будет нормально работать не будут ли косяков при редактировании и сохранении таблиц?

если нет то предложите плиз свои варианты.
С Уважением ко всем Григорий.

ОМГ, ты думаешь тут сборище телепатов?
Как мы можем тебе сказать, как это будет работать, если не видели кода работы с таблицами? Может у тебя таблица в эксклюзивном режиме открывается? Да и вообще для многопользовательской работы я бы лучше Акцез юзал, он точно нормально работает.

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

событие при выборе в меню

procedure TForm1.N2Click(Sender: TObject);

var VIPL :String;

begin



PDOXUSRS :=Edit2.Text;
Session.NetFileDir := PDOXUSRS;



Label38.Caption:='Специалист '+Edit5.Text;
Label39.Caption:='Участок № '+Edit1.Text;
Label40.Caption:='Вид выплаты Выслуга ';


VIPL:='VSL';

Table1.Active:=False;

Table1.TableName:=''+Edit2.Text+VIPL;



DBGrid1.Visible:=True;
Table1.Filter:='NCOMP'+'='+Edit1.Text; // фильтруем табл. по номеру участка , чтобы каждый работал со своими запис.
Table1.Filtered:=true;
Table1.Active:=True;
Label19.Caption:='Всего в базе '+ InttoStr(Table1.RecordCount)+' записей';

end;



событие формшоу

procedure TForm1.FormCreate(Sender: TObject);

var Vars: Tinifile;

begin



Vars:=TiniFile.Create(extractfilepath(paramstr(0))+'sys\ini.ini');
Form1.Caption:=Vars.ReadString('Form','Caption','Ввод Радиации');
Form1.Left:=Vars.ReadInteger('Form','Left',250);
Form1.Top:=Vars.ReadInteger('Form','Top',209);
Form1.Width:=Vars.ReadInteger('Form','Width',788);
Form1.Height:=Vars.ReadInteger('Form','Height',540);
Edit1.Text:=Vars.ReadString('Ncomp','Value','');
Edit2.Text:=Vars.ReadString('Path','value','');
Edit3.Text:=Vars.ReadString('NameOrg','value','');
Edit4.Text:=Vars.ReadString('Nach','value','');
Edit5.Text:=Vars.ReadString('Special','value','');
Vars.Free;

событие на закрытие формы


procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);



var Vars: Tinifile;
begin
Vars:=TiniFile.Create(extractfilepath(paramstr(0))+'sys\ini.ini');
Vars.WriteString('Form','Caption',Form1.Caption);
Vars.WriteInteger('Form','Left',Form1.Left);
Vars.WriteInteger('Form','Top',Form1.Top);
Vars.WriteInteger('Form','Width',Form1.Width);
Vars.WriteInteger('Form','Height',Form1.Height);
Vars.WriteString('Ncomp','value',Edit1.Text);
Vars.WriteString('Path','value',Edit2.Text);
Vars.WriteString('NameOrg','value',Edit3.Text);
Vars.WriteString('Nach','value',Edit4.Text);
Vars.WriteString('Special','value',Edit5.Text);
Vars.Free;

end;

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

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

Добавлено:
Кстати, тупо сохранять значения с формы при ее закрытии - неправильно. Стоит сделать сравнение и если какой-либо параметр изменился, то спросить у пользователя записывать или нет. А то если случайно что-то изменил, то при закрытии программа безоговорочно сохранит изменения (даже если они были нежеланны).

Ну и подставлять в фильтр любое значение Table1.Filter:='NCOMP'+'='+Edit1.Text не есть хорошо - надо все же проверять, что передано из эдитбокса. Чтоб кулхацкеры не тренировались спецсимовлами на подобие ' или " и т.д.

LiquidStorm спасибо за ответ


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

по поводу фильтра таблици то Edit1.Text скрыт от глаз значением визибл
а данные в него заносятся из ihi файла

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

greeng
Я уже писал свое видение , но ты так и не проячснил ситуацию с сетью, и необходимостью использования DBF файлов и BDE.
Еще раз обращаю внимание
a) (DBF или DB)+BDE+РаботаПоСети = Шанс потерять данные
б) (DBF или DB)+BLOB+BDE+РаботаПоСети = Потеря данных
в) (DBF или DB)+BDE+РаботаПоСети+ОченьКоректныйБезопасныйКод = Нормальная работа

greeng
Не думаю, что сортировка может вызвать какие-либо косяки, не зависимо от ключа сортировки.

На счет правки одного рядка двумя (и более) пользователями:
1 первый пользователь входит в режим правки значения в ячейке У строки Х
2 второй пользователь пробует также войти в режим правки строки Х ...

Правильно написанная программа должна заблокировать правку строки Х предоставив эксклюзивное право первому пользователю (блокировка на уровне строк). Если нужна большая гибкость, то можно реализовать блокировку на уровне ячеек - тогда пользователю №2 будет предоставлена возможность правки любой другой ячейки строки Х кроме ячейки У.

Неправильно написанная программа не обеспечит эксклюзивного доступа, в результате чего пользователь №2 получит доступ к правке ячейки У строки Х и в базу будет внесено то значение, которое было сохранено самым последним. Т.е. в таком случае, если пользователь №2 исправил ячейку и перешел к другой, а пользователь №1 продолжал правку и в последствии сохранил значение, то в базе останется именно это значение, не оставив следов правки пользователем №2.

Чтобы такого небыло и нужно вводить блокировку данных.

LiquidStorm

Вы абсолютно правы, но greeng упямянул об использовании BDE. которое все, что Вы написали обеспечивает, но к сожалению не всегда. Точнее говоря по документации всегда, а напрактике, например так: реактировал, сохранял, закрыл приложение, открыл приложение, "Ошибка: индексы устарели" или вообще таблица пустая...
Вобщем был у меня геморой подобного рода, вот и спрашиваю greeng обязательно, ли использовать DBF+BDE, если да то выложу кое какие решения как боротся с глюками BDE, если нет, то как подскажу как с минимальной переделкой кодв перейти на простую SQL платформу.
Может показатся, что я ухожу всторону от первого вопроса greeng, на него можно было сразу ответить "да, все должно работать", но ведь это ответ для приложения без учета работы ядра СУБД, которое обязательно внесет свои поправки...

Цитата:

V1s1ter

Здравствуйте, V1s1ter.
Очень рад что Вы откликнулись помочь
Заранее Спасибо Вам.
Сразу, я неособо подкован в Делфях
Вообщем задача в следующем
нужно вести базу по сети несколькими пользователями
их действия Ввод коректировка записей удаление
почему DBF решил сделать так потому что на выходе нужны файлы в этом формате если можно реализовать на SQL то я буду только рад но нужно тогда сделать процедуру выгрузки в Dbf формат определенных полей так как этот нужен на выходе.
С Уважением Григорий.

В том то и вопрос, что не всегда. Потому часто рекомендуют использовать сторонние продукты для работы с DBF. Таким образом убивается сразу два зайца:
1) не нужно с программой распостранять BDE
2) работа с базой более прозрачна, надежна, да и функций у движка зачастую больше

Для примера могу порекомендовать Halcyon - http://www.griffinsolutions.com/products.php
Он платный, но на просторах Интернет все можно найти )

Можно, конечно, работать с MDB (MS Office Access есть почти на каждом углу) через ADO, еще лучше - поставить фришный сервер MySQL и работать с ним (через тот же ADO, установив на машинку MySQL ODBC Connector).

greeng

Я в всое время перешол в подобной ситуации на AbsoluteDatabase, вроде все нормально.
Преимущества: нет дополнительных инстаялционных пакетов с ядром БД, поддержка многопользовательского режима. Для небольших БД неплохое решение. Уже в ПМ писал если надо сброшу инстал.
Можно по совету LiquidStorm попробывать Halcyon, но я ним не работал и немогу сказать как он себя ведет в сети и с несколькими пользователями.
В общето по хорошему, нужно сначала из условий задачи определится с требованиями к БД, а уж потом выбирать СУБД и компоненты.

Спасибо ОГОМНОЕ V1s1ter
ОЧЕНЬ ПОМОГ Спасибо так же всем отвечавшим тема закрыта
С Уважением Григорий.