Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 10 total
Thread deleted idx file
Wed, Nov 1 2006 9:13 PMPermanent Link

Jon Lloyd Duerdoth
If an idx file is deleted, is anything lost that cannot be
rebuilt.  In other words, if I rebuild all of the indexes
will everything be restored?

Will this still(?) work in the future?

Jon
Wed, Nov 1 2006 9:22 PMPermanent Link

Jeff Cook
Jon Lloyd Duerdoth <jld@welshdragoncomputing.ca> wrote on Wed, 01 Nov 2006 21:08:28 -0500

>
>If an idx file is deleted, is anything lost that cannot be
>rebuilt. In other words, if I rebuild all of the indexes
>will everything be restored?
>
>Will this still(?) work in the future?
>
>Jon

Jon


My understanding in v3 (and I think/hope in v4)  is that structure of the index is stored in the .idx.  You can copy an index from another instance of a table with the same structure and do an index rebuild and it will work.

Cheers

Jeff
--
Jeff Cook
Aspect Systems Ltd
Phone: +64-9-424 5388
Skype: jeffcooknz
www.aspect.co.nz



Wed, Nov 1 2006 10:43 PMPermanent Link

Jon Lloyd Duerdoth
Hi Jeff,

Yes that's what I thought (I'm using v4).  However, I experimented with
deleting the idx and recreated the indexes (using SQL) and everything
seemed to back... maybe I didn't do what I thought I did Smile

(I have been saving backups of the IDX in the past because I thought
 they might be needed for repair)

Jon

Jeff Cook wrote:
> Jon Lloyd Duerdoth <jld@welshdragoncomputing.ca> wrote on Wed, 01 Nov 2006 21:08:28 -0500
>
>> If an idx file is deleted, is anything lost that cannot be
>> rebuilt. In other words, if I rebuild all of the indexes
>> will everything be restored?
>>
>> Will this still(?) work in the future?
>>
>> Jon
>
> Jon
>
>
> My understanding in v3 (and I think/hope in v4)  is that structure of the index is stored in the .idx.  You can copy an index from another instance of a table with the same structure and do an index rebuild and it will work.
>
> Cheers
>
> Jeff
> --
> Jeff Cook
> Aspect Systems Ltd
> Phone: +64-9-424 5388
> Skype: jeffcooknz
> www.aspect.co.nz
>  
>
>
>
Thu, Nov 2 2006 1:03 PMPermanent Link

adam
I have a backup mechanism for DBISAM V3 which copies all the DAT & BLB files from a folder
into a custom formatted ZIP file. I use the Abbrevia open source code which is excellent.
I do not copy/save the IDX files at all.

I have never "lost" anything in terms of data by doing this. The index seems to be
re-created when the first user touches it. However, this does take time.

On the plus side ZIPPING just the BLB & DAT files into a backup means that a DB of several
meg ends up usually at just a few 100k. ... although I think TIM has written a lot of this
into the "BACKUP" method of DBISAM V4 now ... so the code I wrote is redundant!

Adam

Thu, Nov 2 2006 10:54 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Jon,

<< Yes that's what I thought (I'm using v4).  However, I experimented with
deleting the idx and recreated the indexes (using SQL) and everything
seemed to back... maybe I didn't do what I thought I did Smile>>

Jeff is correct, and what you're doing will work fine since the indexes will
be empty when the table is first opened, but recreating them via SQL will
put things back to where they should be.  However, there may be an issue
with the primary key since DBISAM will create that dummy RecordID primary
key when the table is first opened and the .IDX is missing.

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Nov 3 2006 2:21 PMPermanent Link

Jon Lloyd Duerdoth
So as long as I drop the primary index as part of the process that
should eliminate the problem of the RecordID?

Jon

Tim Young [Elevate Software] wrote:
> Jon,
>
> << Yes that's what I thought (I'm using v4).  However, I experimented with
> deleting the idx and recreated the indexes (using SQL) and everything
> seemed to back... maybe I didn't do what I thought I did Smile>>
>
> Jeff is correct, and what you're doing will work fine since the indexes will
> be empty when the table is first opened, but recreating them via SQL will
> put things back to where they should be.  However, there may be an issue
> with the primary key since DBISAM will create that dummy RecordID primary
> key when the table is first opened and the .IDX is missing.
>
Fri, Nov 3 2006 7:12 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Jon,

<< So as long as I drop the primary index as part of the process that
should eliminate the problem of the RecordID? >>

No, you'll need to REDEFINE the primary key in order to modify the RecordID
index that is auto-created.

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Nov 3 2006 10:30 PMPermanent Link

Jon Lloyd Duerdoth
Got it...

Thanks

   Jon

Tim Young [Elevate Software] wrote:
> Jon,
>
> << So as long as I drop the primary index as part of the process that
> should eliminate the problem of the RecordID? >>
>
> No, you'll need to REDEFINE the primary key in order to modify the RecordID
> index that is auto-created.
>
Fri, Nov 3 2006 10:38 PMPermanent Link

Jon Lloyd Duerdoth
Just a further follow-up.

Is there any reason to drop the primary key or will REDEFINE
be all that's needed.

Jon

Jon Lloyd Duerdoth wrote:
> Got it...
>
> Thanks
>
>    Jon
>
> Tim Young [Elevate Software] wrote:
>> Jon,
>>
>> << So as long as I drop the primary index as part of the process that
>> should eliminate the problem of the RecordID? >>
>>
>> No, you'll need to REDEFINE the primary key in order to modify the
>> RecordID index that is auto-created.
>>
Mon, Nov 6 2006 11:30 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Jon,

<< Is there any reason to drop the primary key or will REDEFINE be all
that's needed. >>

REDEFINE is just fine by itself.

--
Tim Young
Elevate Software
www.elevatesoft.com

Image