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

Result := True;

Break;

end;

end;

if Result then Break else TheTable.Prior;

end;

end else begin

TheTable.Next;

while not TheTable.EOF do begin

for i:= LowTheFields to HighTheFields do begin

if DoFindIn(TheTable.Fields[TheFields[i]], SFor) then begin

Result:= True;

Break;

end;

end;

if Result then Break else TheTable.Next;

end;

end;

finally

TheTable.EnableControls;

if not Result then TheTable.GotoBookmark(BM);

TheTable.FreeBookmark(BM);

end;

end;

end.

Событие OncalcFields генерится ОЧЕНЬ часто и может быть необязательным и занимать большое количество времени, например, у вас есть таблица с неким вычисляемым полем, и при каждом редактировании таблицы вызывается следующий код:

MyCalcField.AsInteger:= Table1Field1.AsInteger + 10;

Теперь, если Вы решили пройти последовательно каждую запись огромной таблицы, вы можете представить, какое количество таких событий будет сгенерировано! Они будут необязательны в случае, если вы сделаете обработку полей в отдельной процедуре.

Мой совет следующий: выключите генерацию события OnCalcFields, обработайте все поля и снова включите генерацию данного события, к примеру так:

Procedure TForm1.BigProcessingFunction;

begin

Table1.OnCalcFields:= nil;

<���Включите любые по сложности вычисления в этом месте!>

Table1.OnCalcFields:= Table1OnCalcFields;

end;

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

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

Иногда возникает необходимость поработать с таблицей dBASE напрямую, без Borland Database Engine (BDE). К примеру, если .DBT-файл (содержащий MEMO-данные) для данной таблицы безвозвратно потерян, .DBF-файл становится абсолютно непригодным, поскольку байт в заголовке .DBF-файла указывает, что таблица должна содержать соответствующий MEMO-файл. Решение этой проблемы потребует обнуление этого байта, для того чтобы таблица не указывала на сопутствующий MEMO-файл. Или, если Вам захотелось написать собственную программу для работы с данными.

Ниже приводяся структуры .DBF-файлов для таблиц dBASE. Представлены структуры файлов для различных версий dBASE: dBASE III PLUS 1.1, dBASE IV 2.0, dBASE 5.0 под DOS и dBASE 5.0 для Windows.

n – последний байт массива с описаниями полей. Размер массива зависит от количества полей в табличном файле.

Записи в табличном файле располагаются непосредственно за заголовком таблицы. Данным записи предшествует байт, указывающий на удаленность записи: значение 20h (пробел) указывает что запись не удалена, значение 2Ah (звездочка) – запись была удалена. Поля упаковываются записями без разделителей полей или терминаторов записи. Конец файла помечается единственным байтом (с EOF-маркером), OEM-код которого соответствует значению 26 (1Ah). Вы можете ввести данные в кодовой странице OEM как показано ниже.

MEMO-поля хранят данные в .DBT-файлах, состоящих из перечисляемых последовательных блоков (0, 1, 2 и т.д.). Размер блока равен 512 байт. Первый блок в .DBT-файле (нулевой блок) – заголовок .DBT-файла.

MEMO-поле каждой записи .DBF-файла содержит номер (значение указывается в кодовой странице OEM), указывающий на блок с хранимыми данными. Если поле не содержит никаких данных, .DBF-файл будет заполнен пробелами (20h) (а не числами).

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

Данная информация взята из руководства по использованию dBASE III Plus ("Using dBASE III PLUS", Appendix C).

n - последний байт массива с описаниями полей. Размер массива зависит от количества полей в табличном файле.