Author: Tomas Rutkauskas
How to reindex Paradox tables
Answer:
There are a number of ways to approach this. One way would be to make a call to the
BDE API function DbiRegenIndexes. This insulates you from having to know what
indexes exist, if any, the BDE handling all the code for you. Error checking can be
handled by examining the return value (type DBIResult) or by using the Check
function (defined in the BDE wrapper unit BDE).
1 procedure TForm1.Button4Click(Sender: TObject);
2 var
3 aExclusive, aActive: Boolean;
4 begin
5 with Table1 do
6 begin
7 aActive := Active;
8 Close;
9 aExclusive := Exclusive;
10 Exclusive := True;
11 Open;
12 Check(DbiRegenIndexes(Table1.Handle));
13 Close;
14 Exclusive := aExclusive;
15 Active := aActive;
16 Check(DbiSaveChanges(Table1.Handle));
17 end;
18 end;
As when calling any BDE API function, the BDE API wrapper unit BDE (for Delphi 1,
the units DbiTypes, DbiErrs, and DbiProcs) must be referenced in the Uses section
of the unit from which the call is to be made. The BDE API function DbiSaveChanges,
used here, forces any data changes in memory buffer to be written to disk at that
point.
Another way to handle this situation -- if you know at design-time all the indexes
that will exist for the table -- would be to iterate through the items in the
TIndexDefs object of the TTable component, delete each index (DeleteIndex method),
and then add all needed indexes back (AddIndex method).
19 procedure TForm1.Button3Click(Sender: TObject);
20 var
21 aName: string;
22 i: Byte;
23 aExclusive, aActive: Boolean;
24 begin
25 with Table1 do
26 begin
27 aActive := Active;
28 Close;
29 aExclusive := Exclusive;
30 Exclusive := True;
31 IndexDefs.Update;
32 i := IndexDefs.Count;
33 while i > 0 do
34 begin
35 aName := IndexDefs.Items[i - 1].Name;
36 DeleteIndex(aName);
37 Dec(i);
38 end;
39 AddIndex('', 'MainField', [ixPrimary]);
40 AddIndex('Field1', 'Field1', []);
41 AddIndex('Field2', 'Field2', []);
42 IndexDefs.Update;
43 Exclusive := aExclusive;
44 Active := aActive;
45 Check(DbiSaveChanges(Table1.Handle));
46 end;
47 end;
When iterating through the items in the TIndexDefs object, the cycling must be
backwards, from highest to lowest. This is to account for those table types that
have primary indexes. With those table types, deleting a primary index first causes
all secondary indexes to be unavailable, which interferes with this iterating based
on the TIndexDefs array object contents. This is because a secondary index cannot
exist in some table types (such as Paradox) without an existing primary index. For
the same reason, when recreating the indexes, the process should start with the
primary index and then progress through all secondary indexes (if any are to be
created).
If information about the index definitions is not known at design-time, this
process becomes emminently more complex. The data from all indexes will need to be
saved to memory, the information for all indexes existing simultaneously in memory.
This is because a primary index would need to be deleted at some point (to later be
rebuilt), destroying references to any secondary indexes (whether retrieval for the
secondary indexes takes place before or after deletion of the primary index). To
accomplish this, some multi-entity storage structure would need to be created to
hold a variable number of elements, one element per index. Each element would need
to be able to store the four bits of data that comprise an index's definition: Name
(String), Fields (String), Expression (String), and Options (TIndexOptions). An
array or a TList object of Pascal records with these data fields would suffice for
this purpose.
Once the definition information for all indexes are stored to memory, the succeeding steps are similar to those for the previous method: Delete each index (DeleteIndex) and then recreate each index based on the definition information stored in the array or TList (AddIndex).
|
