Reindexing of Paradox tables

[StevenK]

I've written posts in the past about the problem we experience with Paradox tables whereby we get 'Index out of date' messages on occasions.
We then need to reindex the table(s) in question at the client site to correct the problem.
Someone mentioned that they made use of a process whereby they stepped through all the tables in their database and re-indexed each in turn (perhaps overnight).
I'm familiar with DbiPackTable / DbiDoRestructure.
Is there a similar process that performs a re-index of a Table ?
Does it need to be Opened exclusively for this to occur ?
Can anyone enlighten me as to how I can do this ?
And if there are any pitfalls that I need to be aware of when running a process like this ?
Any help would be appreciated.
Thanks in advance
Steve

 

[towerbase]

You can easily re index Paradox tables from within a Delphi application by dropping and then recreating the index(es).

This can be done using the TTable member functions DeleteIndex and AddIndex OR you can do the same thing with TQuery SQL statements DROP INDEX and CREATE INDEX.

Obviously you will need to prevent your users from running any application that accesses the Paradox tables whilst you are re-indexing them. This takes a little bit of thought in a multi user environment where the tables are on a server.

Andrew

 

[StevenK]

I'm assuming that the AddIndex will require us to pass names of fields and index names.
Is there any process that will do this automatically such that we just point it to a table and run it without worry ?
Thanks so far.
Steve

 

[StevenK]

Someone has suggested making use of the DbiRegenIndexes process - would this also deal with the Primary key ?

 

[towerbase]

If your secondary indexes are corrupted badly enough then using BDE API calls such as DbiRegenIndexes won't work. So you will need to have a fallback facility that recreates the indexes in any case.

Likewise it is possible for the primary key information to be lost and hence you will need a facility that "knows" what the primary key is.

It is not too difficult to write an application that is a generic re indexer that gets its information from some easily maintainable "data dictionary".

This data dictionary could be a simple text file containing (possibly SQL) statements or it could be another database table (but then what happens if the data dictionary loses its index ....?).

Andrew

 

[BTecho]

Hello

To reindex a table you can use the BDE API function DbiRegenIndexes (see BDE32.HLP for more info and examples) also have a look at this snippet from CodeCentral

http://codecentral.borland.com/codecentral/ccweb.exe/listing?id=287

There are a couple of ways to fix the frequent 'Index Out Of Date' error.

1)Set the LocalShare in the BDE Adminstrator to true. Doing this will create Paradox.lck and Pdoxusrs.lck files in the the folders where the tables recide, they will only be automatically delete if you exit the application properly. So on startup of the application before opening the tables make sure to check the existence and delete those files.

if FileExists('c:\db\Paradox.lck') then
DeleteFile('c:\db\Paradox.lck');

if FileExists('c:\db\Pdoxusrs.lck') then
DeleteFile('c:\db\Pdoxusrs.lck');

{Open the Tables}
Table1.Active:=true;
....

2) Call DBISaveChanges(Table's.Handle) on the AfterPost and AfterDelete events of the Table's.


You can assign the same procedure to all the AfterPost and AfterDelete events of the all the Tables on your form

procedure Table1AfterPost(Sender : TDataSet) ;
begin
if(Sender is TBDEDataSet)then
DBISaveChanges(TBDEDataSet(Sender).Handle);
end;

 

[StevenK]

Surely the Local Share property only comes into play when we're dealing with a scenario whereby the Paradox tables are being shared on the local drive (be it via two applications on the same machine or by machine data sharing).
We have the situation whereby our Pardaox tables are sitting on a server and the client workstations connect to them as required.
One issue that keeps being seen when we scour the web for solutions to this problem is the incorrect version of the 'Vredir.vxd' file being used on a Windows '95 client(apparently version number 4.00.1111 is known to be at fault) - we have seen this on at least one of the machines and updated it according to Microsoft.
Whether or not this will ease our pain with this is yet to be seen.
Thanks for help / information so far on this matter.
Regards,
Steve