Tim, Is it possible that DBISAM might think the file doesn't exist if an
AV or Backup tool has it locked when DBISAM goes to open it?

/Matthew Jones/

Robert,

<< How can it be "abolutely false"? I described the very simple steps
required to recreate this situation. Takes about 30 seconds to prove I'm
right. >>

And you're incorrect.  DBISAM does *not* replace the .idx file with empty
index entries if it is corrupted.  It issues an error.  Now, if you wipe out
the index count in the index header with a hex editor or file editor, then
yes, it will appear that there are no indexes anymore.  But it sure as heck
isn't DBISAM doing that.

<< No, the operative part is "trash the idx file". I found it simpler to
just replace the idx file with another file, but trashing the file in any
way would have accomplished the same result. >>

Again, no.

<< I swear I don't understand why you get so emotional about this. >>

Because you're spreading misinformation about our product, and you're not
listening to what I'm telling you.

<< The issue is simply if DBISAM should notify the application when it can't
possibly recover the idx file, instead of building a new one and moving
along. >>

Wrong, again.  DBISAM *does* issue an error, and *does not* overwrite the
..idx file with a new one.

--
Tim Young
Elevate Software
www.elevatesoft.com

Matthew,

<< Tim, Is it possible that DBISAM might think the file doesn't exist if an
AV or Backup tool has it locked when DBISAM goes to open it?  >>

No.  The only time that DBISAM might think that the file doesn't exist when
it does is if the file permissions were so wonky that a user could see the
..dat, but not the .idx.  However, when DBISAM goes to create the .idx file
anyways, the OS would issue an error that DBISAM would raise as an
exception.

There's simply no circumstance where DBISAM will create an empty .idx other
than if the .idx was deleted from the file system prior to DBISAM trying to
open the table.

--
Tim Young
Elevate Software
www.elevatesoft.com

Robert,

The only thing I can think of that you're doing is that you're truncating
the size of the .idx to less than the size of the index header.  If you do
that and DBISAM can't read the header properly, then it will create a new
index file.  But again, this does not apply to the situation that he
describes and only is possible with an .idx that is brand new and then
truncated manually using a hex editor.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:96409D49-D118-408C-B518-1C8B49BA2C6C@news.elevatesoft.com...
> Robert,
>
> << How can it be "abolutely false"? I described the very simple steps
> required to recreate this situation. Takes about 30 seconds to prove I'm
> right. >>
>
> And you're incorrect.  DBISAM does *not* replace the .idx file with empty
> index entries if it is corrupted.  It issues an error.  Now, if you wipe
> out the index count in the index header with a hex editor or file editor,
> then yes, it will appear that there are no indexes anymore.  But it sure
> as heck isn't DBISAM doing that.
>

That is exaclty my point, Tim. You do not know how the file got corrupted,
so all bets are off. So it is then true that under some circumstances,
DBISAM will recreate an index file without letting you know.

> << No, the operative part is "trash the idx file". I found it simpler to
> just replace the idx file with another file, but trashing the file in any
> way would have accomplished the same result. >>
>
> Again, no.
>
> << I swear I don't understand why you get so emotional about this. >>
>
> Because you're spreading misinformation about our product, and you're not
> listening to what I'm telling you.
>
> << The issue is simply if DBISAM should notify the application when it
> can't possibly recover the idx file, instead of building a new one and
> moving along. >>
>
> Wrong, again.  DBISAM *does* issue an error, and *does not* overwrite the
> .idx file with a new one.
>

Step 1:  Create a table using the SQL below
Step 2: Read the table with DBSYS. You will see two records, and an index.
Step 3: Rename or delete the test.idx file
Step 4: Copy the Test.Dat file
Step 5: Rename Copy of Test.dat to test.idx (tell Mr. Gates it is OK to
change the extension)
Step 6: Repeat step 2. Index is gone.

Do I get an Elevate mug?

Robert

/* SQL-92 Table Creation Script with DBISAM Extensions */

CREATE TABLE IF NOT EXISTS "test"
(
  "i" INTEGER,
  "s" VARCHAR(10),
PRIMARY KEY ("RecordID") COMPRESS NONE
LOCALE CODE 0
USER MAJOR VERSION 1
);

CREATE INDEX IF NOT EXISTS "ByInteger" ON "test" ("i");

INSERT INTO "test" VALUES (1,
        'one');
INSERT INTO "test" VALUES (2,
        'two');

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:2643ACF9-7F26-45DF-A7C2-40E83183062B@news.elevatesoft.com...
> Robert,
>
> The only thing I can think of that you're doing is that you're truncating
> the size of the .idx to less than the size of the index header.  If you do
> that and DBISAM can't read the header properly, then it will create a new
> index file.  But again, this does not apply to the situation that he
> describes and only is possible with an .idx that is brand new and then
> truncated manually using a hex editor.
>

Or overlayed with the wrong file, or Windows or the disk drive decided to
destroy your data, or who knows what.

That sounds like a likely scenario (see my previous post). It seems to me
that under those circumstances, it would be better to issue an error. IOW,
except for the case of a missing idx, if the idx found is wrong, or does not
look like an index file, stop the parade. It would be consistent with the
other circumstances where you DO create an exception.

I have no idea how OP trashed his idx file. My humble point was simply that
there IS a way to have DBISAM recreate an index file without you knowing it
is happening. I won.

Robert

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:4F0D4A23-C2C1-422B-B94E-79EBC7317E05@news.elevatesoft.com...
> Robert
>
> Using V4.24b1 I've just tried corrupting the .idx and I get an error 12036
> on trying to open the table
>
>

See response to Tim.

R
> Roy Lambert
>

Robert


Sorry. I don't think you get a mug You need something that has a probability of occurrence slightly higher than that sequence.

Roy Lambert

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:3CC6148B-7CA4-4445-BD17-00B516962D24@news.elevatesoft.com...
> Robert
>
>
> Sorry. I don't think you get a mug You need something that has a
> probability of occurrence slightly higher than that sequence.
>

Really? I guess it's a given that DBISAM is not destroying indexes at
random, otherwise we would no tuse it. But try this:

1. Customer calls to tell you a small table seems to be corrupted.
2. You tell him to restore DAT and IDX from last nite's backup.
3. He gets confused, places the DAT as both DAT and IDX

DBISAM will silently rebuild the IDX file without the indexes and without
letting the application know. The point is not if that happens all the time
(obvously not) but if should EVER happen. IMO, DBISAM should notify you any
time it rebuilds indexes. Even in the case where the IDX file is missing.

Robert

Robert


I just tried your process in V24.b1. I get an error

8961 header information corrupt in table Bayesian

still no mug

Roy Lambert