Tim

Probably as a result of messing around I've been doing recently I've had to do a repair on a table a couple of times. The report which prompted the repair was along the lines of "missing key from index Staff". Which makes me think it would be nice to have a REBUILD INDEX ability.

I know I can DROP and CREATE, and I can even get the information necessary to CREATE the index from the config tables (providing I do it before DROPping it but I think it would be a nice bit of functionality to have built in.

Before I head off to write my own in Delphi what do you think?

Roy Lambert

Roy, would not "REPAIR TABLE yourtable" work?

From the manual (FYI): Note, repairing a table may cause the size of the
..EDBIdx file for the table to increase slightly. This is normal and part of
the repair process.

Daniel


Yes if it just does the appropriate index. I don't know if it does or does a lot more. I suspect the latter.

Roy Lambert

Roy,

<< Probably as a result of messing around I've been doing recently I've had
to do a repair on a table a couple of times. The report which prompted the
repair was along the lines of "missing key from index Staff". Which makes me
think it would be nice to have a REBUILD INDEX ability. >>

You shouldn't have to rebuild an index from just normal operation.  What
exactly constitutes "messing around" ?

The reason that this isn't a viable feature is that any problem with one
index indicates potential problems with other indexes, and the table in
general, and a complete REPAIR TABLE would be required to ensure that the
damage is not present elsewhere.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>You shouldn't have to rebuild an index from just normal operation. What
>exactly constitutes "messing around" ?

It includes, but isn't limited to:

a) on the live database the notebook on which my email app sits (uploading and downloading) deciding to go into hibernate mode whilst it was running, and whilst Acronis was running

b) on the development app I was working on the email forwarding (I wasn't copying attachments) and had the copy on insert flag true and forgot to clear the autoinc primary key before hitting the post button, and the delete button

c) on the development app importing the data from the live system after deleting the table data files rather than emptying

I'm sure there was a lot more but it wasn't until well after the event that I thought about it.

>The reason that this isn't a viable feature is that any problem with one
>index indicates potential problems with other indexes, and the table in
>general, and a complete REPAIR TABLE would be required to ensure that the
>damage is not present elsewhere.

Fair enough.

Roy Lambert [Team Elevate]

Roy,

<< It includes, but isn't limited to: >>

Okay, but none of those items should corrupt a table.  Hibernate might be a
bit dicey if it forces a suspension of the application, but I would have to
verify that before I could say for sure.

--
Tim Young
Elevate Software
www.elevatesoft.com