>When indexes are lost in DBISAM, sometimes we can "save" only primary index on repair.
>What happening when EDB index file lost (for example: deleted)? Can EDB repair it from catalog?

I just tried it - I deleted the index file for a table. Opened the table and couldn't see any records. Did REPAIR TABLE Companies and everything back as it should be.

>What happening when the catalog's structure and table structure isn't identical?
>For example:
>Filesystem injured in a corporation because of HDD failure.
>One table destroyed, and we must replaced it with older version (from Backup).
>But this table structure is different than latest, for example one field is missing from it.
>Then...? Error? Ignored? Error to logfile?

You have a problem There is a way round it but its a bit more work:

1. restore the database to a different folder
2. create a session with bold old and new databases
3. DELETE FROM live database if necessary
4. INSERT FROM old database to new database

Roy Lambert [Team Elevate]

<< When indexes are lost in DBISAM,  sometimes we can "save" only primary
index on repair. What happening when EDB index file lost (for example:
deleted)? Can EDB repair it from catalog? >>

Yes, see Roy's response for how to do it.  This is one of the main benefits
of having the metadata in the catalog instead of the table files.

<< What happening when the catalog's structure and table structure isn't
identical? >>

You can't just restore one table from backup, without also restoring the
associated catalog.  What you should do is this (2.03 B7 or higher):

1) Restore the database catalog and the desired table from backup into a
different database directory.

2) Define a new database that points to the database directory where the
restored database catalog and table are located.

3) Alter the table so that it matches the new table structure.

4) Now copy the table files (<tablename>.edbtbl/.edbidx/.edbblb/.edbpbl)
back over to the existing database directory.

This works with 2.03 B7 or higher because that build, and later builds, use
a new checksum algorithm to determine when a table file matches a catalog.
As long as the basic structure of the columns and indexes matches the same
information in the catalog, ElevateDB will allow you to use the catalog with
the table files.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dear Tim,

> 4) Now copy the table files (<tablename>.edbtbl/.edbidx/.edbblb/.edbpbl)
> back over to the existing database directory.
>
> This works with 2.03 B7 or higher because that build, and later builds, use
> a new checksum algorithm to determine when a table file matches a catalog.
> As long as the basic structure of the columns and indexes matches the same
> information in the catalog, ElevateDB will allow you to use the catalog with
> the table files.

I tested this i found pretty useful.

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Tim


>3) Alter the table so that it matches the new table structure.

Can you just expand a bit on what the table structure consists of in these circumstances? Is it just column definitions or does it include the indices, triggers etc?

Roy Lambert

Roy,

<< Can you just expand a bit on what the table structure consists of in
these circumstances? Is it just column definitions or does it include the
indices, triggers etc? >>

Simply anything that is stored in the table files, which is basic column
information and indexes.  Triggers are not accounted for, nor are
constraints (apart from the indexes which are used to implement certain
constraints).  Things like names are not accounted for, either.  EDB doesn't
care what a column or index name is, as long as the data type and size
match.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Simply anything that is stored in the table files, which is basic column
>information and indexes. Triggers are not accounted for, nor are
>constraints (apart from the indexes which are used to implement certain
>constraints). Things like names are not accounted for, either. EDB doesn't
>care what a column or index name is, as long as the data type and size
>match.

That last bit is neat.

Roy Lambert