Валентин Озеров - Советы по Delphi. Версия 1.4.3 от 1.1.2001

{$R *.DFM}

{тип структуры данных для сохранения информации о предыдущем обратном вызове}

typeTDbiCbInfo = record

ecbType : CBType;

iClientData : longint;

DataBuffLn : word;

DataBuff : pCBPROGRESSDesc;

DbiCbFn : pointer;

end;

typePDbiCbInfo = ^TDbiCbInfo;

{Наша функция обратного вызова}

functionDbiCbFn(ecbType: CBType; iClientData: Longint; CbInfo: pointer): CBRType stdcall;

vars : string;

begin

{Проверяем, является ли тип обратного вызова тем, который мы ожидаем}

ifecbType = cbGENPROGRESS then begin

{если iPercentDone меньше нуля, извлекаем число}

{обработанных записей из параметра szMsg}

ifpCBPROGRESSDesc(cbInfo).iPercentDone < 0 then begin

s := pCBPROGRESSDesc(cbInfo).szMsg;

Delete(s, 1, Pos(': ', s) + 1);

{Вычислям процент выполненного и изменяем линейку прогресса}

Form1.ProgressBar1.Position :=Round((StrToInt(s) / Form1.Table1.RecordCount) * 100);

end else begin

{Устанавливаем линейку прогресса}

Form1.ProgressBar1.Position:=pCBPROGRESSDesc(cbInfo).iPercentDone;

end;

end;

{существовал ли предыдущий зарегистрированный обратный вызов?}

{если так - осуществляем вызов и возвращаемся}

ifPDbiCbInfo(iClientData)^.DbiCbFn <> nil then

DbiCbFn:=pfDBICallBack(PDbiCbInfo(iClientData)^.DbiCbFn)(ecbType,PDbiCbInfo(iClientData)^.iClientData,cbInfo)

elseDbiCbFn := cbrCONTINUE;

end;

procedureTForm1.Button1Click(Sender: TObject);

var

CbDataBuff: CBPROGRESSDesc; {Структура DBi}

OldDbiCbInfo : TDbiCbInfo; {структура данных должна хранить информацию о предыдущем обратном вызове}

begin

{Убедимся в том, что перемещаемая таблица открыта}

Table1.Open;

{Убедимся в том, что таблица-приемник закрыта}

Table2.Close;

{получаем информацию о любом установленном обратном вызове}

DbiGetCallBack(Table2.Handle, cbGENPROGRESS, @OldDbiCbInfo.iClientData, @OldDbiCbInfo.DataBuffLn, @OldDbiCbInfo.DataBuff, pfDBICallBack(OldDbiCbInfo.DbiCbFn));

{регистрируем наш обратный вызов}

DbiRegisterCallBack(Table2.Handle, cbGENPROGRESS, longint(@OldDbiCbInfo), SizeOf(cbDataBuff), @cbDataBuff, @DbiCbFn);

Form1.ProgressBar1.Position := 0;

BatchMove1.Execute;

{если предыдущий обратный вызов существовал - вновь устанавливаем его,}

{в противном случае "отрегистрируем" наш обратный вызов}

ifOldDbiCbInfo.DbiCbFn <> nil then

DbiRegisterCallBack(Table2.Handle, cbGENPROGRESS, OldDbiCbInfo.iClientData,

OldDbiCbInfo.DataBuffLn, OldDbiCbInfo.DataBuff, OldDbiCbInfo.DbiCbFn)

else

DbiRegisterCallBack(Table2.Handle, cbGENPROGRESS, longint(@OldDbiCbInfo),

SizeOf(cbDataBuff), @cbDataBuff, nil);

{Показываем наш успех!}

Table2.Open;

end;

end.

Если два различных пользователя подключают два различных сетевых каталога (net control directories, NCD), но при этом пути к каталогам одинаковые (это не трудно при работе с сетью), BDE думает, что в этом случае используются одни и те же NCD. Это может привести к _огромным_ проблемам.

Если два пользователя подключают один и тот же NCD, но с разными путями, BDE думает что используются два различных NCD и не позволяет второму пользователю редактировать таблицу. Например, пользователь A подключил NCD по пути G:\DATA\BDENET. Пользователь B подключил NCD по пути H:\BDENET, где H: подключен по пути G:\DATA. В этом случае оба пользователя пытаются использовать один и тот же NCD, но BDE не знает об этом.

Если в вышеприведенном примере пользователи используют один и тот же путь, но с различными буквами диска, BDE позволяет работать обоим пользователям, подразумевая, что они используют один и тот же NCD. Так, если пользователь A подключен к G:\DATA\BDENET, а пользователь B к H:\DATA\BDENET, BDE даст работать обоим.

Это полезно в peer-to-peer сети, где сервер также является и рабочей станцией. В этом случае некоторые (какие?) peer-to-peer OS не позволят серверу подключить сетевой диск к самому себе (я не уверен что у них невозможен эквивалент SUBST, но, по крайней мере, у тех OS, которые я знаю, это отсутствует) так что сервер может использовать только диск C: (или D:, или какой-то другой локальный диск), а рабочая станция нет, поскольку сама имеет собственный локальный диск C:.

Richard Davis

Дополнение от Mark Ostroff (Borland):

В дополнение к ИЗУМИТЕЛЬНОМУ ответу Richard'а, пожалуйста помните об одной ОЧЕНЬ важной вещи… НИКОГДА не допускайте ситуации (в ЛЮБОЙ сети), при которой вы имеете нескольких пользователей, имеющих доступ к одним и тем же таблицам, но использующих разные физические NET-файлы. Это создает ОГРОМНЫЕ проблемы, особенно в в корпоративных и peer-to-peer сетях.