Sorry to bother with an issue concerning an old 3.30 version.

I have tried the archives but came up with very few answers, so I'll try
here:

I'm having one customer who has a table that just won't optimize.
OptimizeTable always throws a "duplicate index" error on some temporary
table (numbered name). Have tried the optimize on all the indexes, no
difference. Have ran a RepairTable with and without ForceIndexRebuild, no
difference. Don't know what I can try next and any clues are welcome.

Cheers,
Dom

Dom,

<< I'm having one customer who has a table that just won't optimize.
OptimizeTable always throws a "duplicate index" error on some temporary
table (numbered name). Have tried the optimize on all the indexes, no
difference. Have ran a RepairTable with and without ForceIndexRebuild, no
difference. Don't know what I can try next and any clues are welcome. >>

If you send me the table as a .zip, I can fix it for you.  It's probably
something messed up with one of the rows.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote
> If you send me the table as a .zip, I can fix it for you.  It's probably
> something messed up with one of the rows.

If I send it to you, could you indicate which row, so I can delete it in the
active table, or would that not work? The DB is in constant use, and of a
very classified nature, but for the latter I'm sure I can count on your
discretion?

Dominic,

<< If I send it to you, could you indicate which row, so I can delete it in
the active table, or would that not work? >>

Sure, that would be fine.  Either that, or I can just simply delete it and
tell you which one it was.

<< The DB is in constant use, and of a very classified nature, but for the
latter I'm sure I can count on your
discretion?  >>

Absolutely.  I don't keep things around here for more than a week anyways
because my "support" directory fills up so quickly with test projects, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote
> Either that, or I can just simply delete it and tell you which one it was.

You made me try something out and it worked perfectly! Why didn't you
include this simple thing in your RepairTable procedure?

tbData.Open;
while not tbData.eof do begin
 try
   if tbDataTOE.AsString[1] = '0' then // whatever, really. It just needs
to crash on reading the record. (it has to return the first digit of a date
here. Impossible to be empty.)
     tbData.Delete
   else
     tbData.Next
 except
   tbData.Delete
 end
end;
tbData.Close;

Did the trick.

Thanks,
Dom

Dom,

<< You made me try something out and it worked perfectly! Why didn't you
include this simple thing in your RepairTable procedure? >>

Well, we try to stay away from deleting records automatically unless they
absolutely must go, such as is the case with a record that contains a
duplicate primary or unique key.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote
> Well, we try to stay away from deleting records automatically

You're right, of course; very wise.