"Dave Harrison" <daveh_18824@spammore.com> wrote in message
news:B9064EDB-1DD7-4633-B5F3-73790D3E62C9@news.elevatesoft.com...
> Robert wrote:
>
>> "Danny Humphress" <danny@_no_spam_remove_this_SurpassSupport.com> wrote
>> in message
>> news:5B993A48-1C5F-41D3-B7DD-6D1B6C5F27D7@news.elevatesoft.com...
>>
>>>Tim,
>>>
>>>It used to work fine.
>>>
>>
>>
>> Use SQL to drop and rebuild the indexes.
>>
>> Robert
>>
>
> Robert,
>     Yes, but how does he know if the indexes need rebuilding?

That's a completely separate problem. See Danny's posting where he states
"The bottom line is that I need a way to get rid of the old index file and
rebuild it from scratch (short of a full-blown table repair)." He wants to
rebuild indexes, and you can do that in SQL whether you are running shared
file or C/S. For each index DROP the index if exists, create the index.
Using SQL, you don't need access to the IDX file.

Robert

Danny,

<< It used to work fine. >>

I don't see how it (if you mean replacing the .idx with an empty one) could
have worked fine.  DBISAM has never automatically repaired or rebuilt
indexes unless the .IDX file is missing completely.

<< The bottom line is that I need a way to get rid of the old index file and
rebuild it from scratch (short of a full-blown table repair). I do this as a
part of routine database maintenance and, more importantly, after restoring
..dat/.blb files from a backup. That used to be as simple as DeleteAllIndexes
followed by adding indexes to the table. Now it doesn't work. >>

As I said before - I can't replicate it here.  If you want to send me the
code that you're using that reproduces the issue, I'll be happy to look at
it and see what I can find.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

It doesn't work when there is a default primary index (on RecordID). It DOES
work, however, if there are other fields in the primary index.

I know it used to work because we have relied on it for years when clients
send us backups, which do not include .idx files. On our side, we have our
software create an empty database, we restore the .dat and .blb files, drop
the indexes using DeleteAllIndexes and then rebuild the indexes. It worked
flawlessly until recently. I'm not sure what has changed.

There really isn't much code to send. It's just:

DBISAMTable1.DeleteAllIndexes

Shouldn't that drop all indexes including the primary index and then create
a new default primary index on RecordID? It does seem to do that but if the
OLD primary index is already on RecordID, it doesn't do anything. I suspect
that is the difference -- it doesn't bother to create a new primary index if
the primary index is already on RecordID.

Danny



"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:51E5C21E-0920-469B-AD0D-89DD2847AAC0@news.elevatesoft.com...
> Danny,
>
> << It used to work fine. >>
>
> I don't see how it (if you mean replacing the .idx with an empty one)
> could have worked fine.  DBISAM has never automatically repaired or
> rebuilt indexes unless the .IDX file is missing completely.
>
> << The bottom line is that I need a way to get rid of the old index file
> and rebuild it from scratch (short of a full-blown table repair). I do
> this as a part of routine database maintenance and, more importantly,
> after restoring
> .dat/.blb files from a backup. That used to be as simple as
> DeleteAllIndexes followed by adding indexes to the table. Now it doesn't
> work. >>
>
> As I said before - I can't replicate it here.  If you want to send me the
> code that you're using that reproduces the issue, I'll be happy to look at
> it and see what I can find.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Danny Humphress wrote:
> Tim,
>
> It doesn't work when there is a default primary index (on RecordID). It
> DOES work, however, if there are other fields in the primary index.
>
> I know it used to work because we have relied on it for years when
> clients send us backups, which do not include .idx files. On our side,
> we have our software create an empty database, we restore the .dat and
> .blb files, drop the indexes using DeleteAllIndexes and then rebuild the
> indexes. It worked flawlessly until recently. I'm not sure what has
> changed.
>
> There really isn't much code to send. It's just:
>
> DBISAMTable1.DeleteAllIndexes
>
> Shouldn't that drop all indexes including the primary index and then
> create a new default primary index on RecordID? It does seem to do that
> but if the OLD primary index is already on RecordID, it doesn't do
> anything. I suspect that is the difference -- it doesn't bother to
> create a new primary index if the primary index is already on RecordID.
>
> Danny
>

What happens when you set:

DBISAMTable1.IndexFieldNames := '';
DBISAMTable1.DeleteAllIndexes;

Maybe it didn't delete the primary index because it was being used if
the table was open? Have you tried closing the table before deleting the
index?


Dave

Danny,

<< It doesn't work when there is a default primary index (on RecordID). It
DOES work, however, if there are other fields in the primary index.

I know it used to work because we have relied on it for years when clients
send us backups, which do not include .idx files. On our side, we have our
software create an empty database, we restore the .dat and .blb files, drop
the indexes using DeleteAllIndexes and then rebuild the indexes. It worked
flawlessly until recently. I'm not sure what has changed. >>

Shouldn't that drop all indexes including the primary index and then create
a new default primary index on RecordID? >>

Yes.   But if there was an already just the "auto" index on the RecordID
column, then you cannot expect the DeleteAllIndexes call to do the
equivalent of a RepairTable on that index.   A DeleteAllIndexes is just what
it says, while a RepairTable is what you want.

--
Tim Young
Elevate Software
www.elevatesoft.com