"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:AF4681B4-DFE6-4CD4-A0A1-FCFBE953B97B@news.elevatesoft.com...
> Robert
>
>
> I just tried your process in V24.b1. I get an error
>
> 8961 header information corrupt in table Bayesian
>
> still no mug
>

You did not *exactly* reproduce my experiment, Igor. As Tim indicated, the
probable cause for DBISAM's confusion is that the file replacing the idx
file is smaller than the original idx. Try it with my test table, or believe
me.

Robert

Robert


Correct I did not reproduce your experiment - I reproduced your process (including a replacement for the .idx that is smaller than the original .idx) and I get an error message. I've just tried again and I still get an error message!

Using your test stuff I agree I don't get an error. It may be something to do with a file being contained wholly within one disk block.

I'll still deny you the mug cos its very artificial, very hard to produce and very unlikely to occur in the wild. Sorry.

Roy Lambert

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:B3778169-B571-46B6-B232-9BCAA38255F2@news.elevatesoft.com...
> Robert
>
>
> Correct I did not reproduce your experiment - I reproduced your process
> (including a replacement for the .idx that is smaller than the original
> .idx) and I get an error message. I've just tried again and I still get an
> error message!
>
> Using your test stuff I agree I don't get an error. It may be something to
> do with a file being contained wholly within one disk block.
>
> I'll still deny you the mug cos its very artificial, very hard to produce
> and very unlikely to occur in the wild. Sorry.
>

All I can say is that I would be more than happy to give mugs by the dozen
to customers who give me a well documented way to reproduce a problem
instead of the stuff I usually get "I got an error message last Friday, or
maybe it was last Wednesday, but I don't remember what it was. But right now
the system is out of balance, I think".

As to the issue of the probability of my example occuring in the wild, I
can't tell, neither can you, unless we knew exactly why it is happening in
the first place. Rioght now we're both guessing that it has something to do
with file sizes. But so far it's just a guess.

Robert

Robert

>All I can say is that I would be more than happy to give mugs by the dozen
>to customers who give me a well documented way to reproduce a problem
>instead of the stuff I usually get "I got an error message last Friday, or
>maybe it was last Wednesday, but I don't remember what it was. But right now
>the system is out of balance, I think".

Amen to that

Roy Lambert

Robert,

<< Step 1:  Create a table using the SQL below >>

Yes, and this is exactly what I posted in my other message.  You're manually
editing the .idx in such a way so that the index header is smaller than what
it should be.  In this case, DBISAM replaces the index file with a valid one
since it is assumed that any index file that has a size *smaller* than what
the *header* should be is corrupt.  IOW, it is impossible for the index file
to contain valid index information in the header.   And, of course, as I
originally stated, none of this applies to the original poster.  Therefore,
you've simply managed to waste everyone's time in your constant pursuit to
prove me wrong about something.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:FF58CD7F-EA2F-4643-B24B-E4B3267B5B30@news.elevatesoft.com...
> Robert,
>
> << Step 1:  Create a table using the SQL below >>
>
> Yes, and this is exactly what I posted in my other message.  You're
> manually editing the .idx in such a way so that the index header is
> smaller than what it should be.  In this case, DBISAM replaces the index
> file with a valid one since it is assumed that any index file that has a
> size *smaller* than what the *header* should be is corrupt.  IOW, it is
> impossible for the index file to contain valid index information in the
> header.   And, of course, as I originally stated, none of this applies to
> the original poster.  Therefore, you've simply managed to waste everyone's
> time in your constant pursuit to prove me wrong about something.
>

This is unbelievable.

Could you please point to the place in the DBISAM documentation where it is
stated that if the index file is under a certin size, DBISAM will consider
it a "normal" corruption and build a new IDX, whereas if it is over that
magical size you get an exception?

Let's take it in parts, as Jack D. Ripper would say:

1. OF COURSE I manually edited the IDX file. How else could I get a
corrupted file?
2. I still think it is inconsistent to in one case (missing or "small" idx)
simply rebuild the file, while in another case you raise an exception. Now,
there might be very valid reasons why that is so, but I can't see them.
Especially in the case of someone using only SQL (presumably, tTables would
crash with an invalid index), rebuilding the index will not cause the
program to crash. Just that all the queries will be a lot slower, and the
user will be scratching his head trying to figure out why.
3. I have better things to do than to try to prove you wrong. I was trying
to figure out why the OP had the problem he faced. Jus' trying to be
helpful.
4. In the process, I found a strange situation that seemed to parallel what
OP had seen. I posted it in this thread, with instructions on how to
reproduce.

Now this is the second posting in this thread where you are being rude and
unprofessional to me. I suggest you take a deep breath, calm down, and
either fix the bug in DBISAM, explain why it is not a bug, or admit it is a
bug but you won't fix it. Your choice. What I can't see is why a paying
customer has to put up with this abuse, especially since what I was trying
to do was to try to shed some light on the original problem (which, as far
as I know, still is not solved).

Robert

Robert,

<< Could you please point to the place in the DBISAM documentation where it
is stated that if the index file is under a certin size, DBISAM will
consider it a "normal" corruption and build a new IDX, whereas if it is over
that magical size you get an exception? >>

It doesn't mention it, namely because it doesn't need to.  If the .IDX is
below the size *required to store the number of index headers for the
defined number of indexes in the table*, then it is corrupt and incomplete.
This means that either the index count is corrupt or the index headers
themselves are corrupt or truncated, which in turn means that the index
header and index definitions are not usable.  A repair would simply perform
the same operation - overwrite the index header with a valid header in order
to fix the structural issue.

<< 1. OF COURSE I manually edited the IDX file. How else could I get a
corrupted file? >>

My point was that manually corrupting an .IDX file in the fashion that you
did is entirely *not* what would happen in the wild.  I can't think of any
scenario where an .IDX file would get truncated by the file system to be
less than the appropriate index header size.  It simply wouldn't happen that
way.  The file system may write junk in the index header, but it sure as
hell won't truncate the file in that way.  I've never seen Windows do such a
thing.

<< 2. I still think it is inconsistent to in one case (missing or "small"
idx) simply rebuild the file, while in another case you raise an exception.
Now, there might be very valid reasons why that is so, but I can't see
them.>>

The valid reason was a case that a customer presented to us where someone
copied over zero-length files in place of the .idx files.  They asked if in
such a case DBISAM could respond by recreating an empty .idx file instead.

<< Especially in the case of someone using only SQL (presumably, tTables
would crash with an invalid index), rebuilding the index will not cause the
program to crash. Just that all the queries will be a lot slower, and the
user will be scratching his head trying to figure out why. >>

See above.  a) I've never seen the situation you described happening in a
working application, and b) it would only occur if you took the steps that
you did by reducing the size of the index file below the minimum required to
store the required index definitions.

<< 3. I have better things to do than to try to prove you wrong. I was
trying to figure out why the OP had the problem he faced. Jus' trying to be
helpful. >>

Really ?  So that's why you finish posts with "I won." ?

<< 4. In the process, I found a strange situation that seemed to parallel
what OP had seen. I posted it in this thread, with instructions on how to
reproduce. >>

Yes, and you proceeded to go on in a series of posts about how you were
right and I was wrong.

<< Now this is the second posting in this thread where you are being rude
and unprofessional to me. I suggest you take a deep breath, calm down, and
either fix the bug in DBISAM, explain why it is not a bug, or admit it is a
bug but you won't fix it. Your choice. What I can't see is why a paying
customer has to put up with this abuse, especially since what I was trying
to do was to try to shed some light on the original problem (which, as far
as I know, still is not solved). >>

My issue with these two situations is the same.  You don't want to hear what
I have to say - what you want to hear is that you're right and I'm wrong.
Paying for our software does not entitle you to come on these newsgroups and
attempt to bully or embarass me into admitting that there is something wrong
with DBISAM when there isn't.   This thread is a perfect case of this - how
long do you think that this issue that you're complaining about has been in
DBISAM ?  And how many reported issues have arisen because of it ?  The
answer is over a year, and 0:

http://www.elevatesoft.com/scripts/incident.dll?action=viewrep&category=dbisam&release=4.22&type=f&incident=2160

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:1DCABD9F-52C3-47E5-AB02-4A477FEB8B70@news.elevatesoft.com...
>
> My issue with these two situations is the same.  You don't want to hear
> what I have to say - what you want to hear is that you're right and I'm
> wrong.

Look, Tim, I was trying to create a situation to see if I could help OP, and
in the process stumbled upon a situation that you claimed is absolutely
impossible (in fact, you say that what I claim happened is "not true").
Well, what you said could neve happen DID happen, I posted the steps
necessary to make it happen, and proceeded (very unwisely, since you seem to
lack any sense of humor) to rattle your chain a bit.

> long do you think that this issue that you're complaining about has been
> in DBISAM ?

I'm not complaining. I simply think that DBISAM instead of doing an
automatic repair when it finds a missing or invalid IDX file should throw an
exception, same as when the IDX file is the right size but  is corrupted.
The message to the application should the same in all these cases "your
index files are missing or are no good, so bad things can happen if you keep
on processing". That would be consistent, in that EVERY case of a bad or
missing index file gets reported the same way. It is up to the application
to respond (the programmer always has the choice to trigger an automatic
repair, basically what happens now).

No big deal.

Robert

Tim,

I am not complaining either, but I also would prefer ALWAYS an error message when something is wrong with the indexes or tables, instead of an
automatic creation.

Is the design of EDB the same way as dbisam 4.22 and on ?

Could you tell me the minimum size of the idx file so I can do the check myself ?

Thanks,
Wim

Robert,

<< Look, Tim, I was trying to create a situation to see if I could help OP,
and in the process stumbled upon a situation that you claimed is absolutely
impossible (in fact, you say that what I claim happened is "not true"). >>

What you said was this:

"If the IDX file is corrupted, DBISAM creates a new one, and you have lost
all your indexes."

Which is not true.  Only in *one* very specific case does DBISAM create a
new index header, and that is what I've already outlined.

<< Well, what you said could neve happen DID happen, I posted the steps
necessary to make it happen, and proceeded (very unwisely, since you seem to
lack any sense of humor) to rattle your chain a bit. >>

Well, for starters, you could start indicating that you're kidding by
putting some sort of or next to your sentences so that I know that
you're kidding.  Reading your statements, it sure doesn't seem like you're
kidding on this end.

<< I'm not complaining. I simply think that DBISAM instead of doing an
automatic repair when it finds a missing or invalid IDX file should throw an
exception, same as when the IDX file is the right size but  is corrupted.
The message to the application should the same in all these cases "your
index files are missing or are no good, so bad things can happen if you keep
on processing". That would be consistent, in that EVERY case of a bad or
missing index file gets reported the same way. It is up to the application
to respond (the programmer always has the choice to trigger an automatic
repair, basically what happens now). >>

Well, I may take that "feature" out anyways since it has caused such a
stink.  It was only put in there anyways by the request outlined in the
incident report that I linked to.

--
Tim Young
Elevate Software
www.elevatesoft.com