This weekend our customer complained about a very slow query.
The slow-down was caused by a table that lost ALL the indexes. Data itself was ok, just
the whole index information was lost.
(.dat file seemed to be ok, .idx was existent)
No error, no error report after table repair, just no indices anymore.
We had the same effect some weeks ago with another table (but with 4.22B5).  
I can exclude that someone deleted the file manually.

We are running DBISAM 4.25 Build 4 in client-Server mode. Some client programs running
multi-threaded, most client  programs  are single threaded.
No server modifications, no triggers, no remote procedures, just  the server program out
of the box;
But : We are running two seperate DBISAM-Servers on the same machine on different ports.

Has anyone else experienced a similar problem ?  Any suggestions ?

Thanks,
Marco

I've had the same problem before using DBISAM 3.30 on some of my customers DB.  But wasn't able to know the cause of it.  All I did to solve the
problem is running some scripts to re-create the indexes.  One thing I note:  It only happen to heavy use tables.



msproconnet <m.suffel@proconnet.de> wrote:

This weekend our customer complained about a very slow query.
The slow-down was caused by a table that lost ALL the indexes. Data itself was ok, just
the whole index information was lost.
(.dat file seemed to be ok, .idx was existent)
No error, no error report after table repair, just no indices anymore.
We had the same effect some weeks ago with another table (but with 4.22B5).  
I can exclude that someone deleted the file manually.

We are running DBISAM 4.25 Build 4 in client-Server mode. Some client programs running
multi-threaded, most client  programs  are single threaded.
No server modifications, no triggers, no remote procedures, just  the server program out
of the box;
But : We are running two seperate DBISAM-Servers on the same machine on different ports.

Has anyone else experienced a similar problem ?  Any suggestions ?

Thanks,
Marco

Marco,

<< This weekend our customer complained about a very slow query. The
slow-down was caused by a table that lost ALL the indexes. Data itself was
ok, just the whole index information was lost. (.dat file seemed to be ok,
..idx was existent) No error, no error report after table repair, just no
indices anymore. We had the same effect some weeks ago with another table
(but with 4.22B5).   I can exclude that someone deleted the file manually.
>>

There is absolutely no way that DBISAM removed the indexes for a table on
its own.  Someone or some code somewhere must have deleted them or the .IDX
file entirely.

--
Tim Young
Elevate Software
www.elevatesoft.com

Abdulaziz,

<< I've had the same problem before using DBISAM 3.30 on some of my
customers DB.  But wasn't able to know the cause of it.  All I did to solve
the problem is running some scripts to re-create the indexes.  One thing I
note:  It only happen to heavy use tables. >>

See my reply to Marco - indexes just don't disappear in DBISAM.  Someone or
something is deleting them or the .IDX file.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

don't misunderstand me. I do not say that DBISAM is deleting the indexes.

I'm just wondering what happens if the .idx file is corrupted (like .dat files sometimes
can be corrupted). If DBISAM can't read the idx file then a new empty one is created and i
will not get an error message, right ???

Marco





"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Marco,

<< This weekend our customer complained about a very slow query. The
slow-down was caused by a table that lost ALL the indexes. Data itself was
ok, just the whole index information was lost. (.dat file seemed to be ok,
..idx was existent) No error, no error report after table repair, just no
indices anymore. We had the same effect some weeks ago with another table
(but with 4.22B5).   I can exclude that someone deleted the file manually.
>>

There is absolutely no way that DBISAM removed the indexes for a table on
its own.  Someone or some code somewhere must have deleted them or the .IDX
file entirely.

--
Tim Young
Elevate Software
www.elevatesoft.com

"msproconnet" <m.suffel@proconnet.de> wrote in message
news:4DF26819-63FA-4DEF-8A91-300020F0E159@news.elevatesoft.com...
> Tim,
>
> don't misunderstand me. I do not say that DBISAM is deleting the indexes.
>

It does, in a way. If the IDX file is corrupted, DBISAM creates a new one,
and you have lost all your indexes. Does not tell you about it either. Just
go to dbsys, delete an idx file, put any garbage in its place, and open the
table. Look at the index structure, it is blank.

Robert

> I'm just wondering what happens if the .idx file is corrupted (like .dat
> files sometimes
> can be corrupted). If DBISAM can't read the idx file then a new empty one
> is created and i
> will not get an error message, right ???
>
> Marco
>
>
>
>
>
> "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:
>
> Marco,
>
> << This weekend our customer complained about a very slow query. The
> slow-down was caused by a table that lost ALL the indexes. Data itself was
> ok, just the whole index information was lost. (.dat file seemed to be ok,
> .idx was existent) No error, no error report after table repair, just no
> indices anymore. We had the same effect some weeks ago with another table
> (but with 4.22B5).   I can exclude that someone deleted the file manually.
> >>
>
> There is absolutely no way that DBISAM removed the indexes for a table on
> its own.  Someone or some code somewhere must have deleted them or the
> .IDX
> file entirely.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Marco,

<< don't misunderstand me. I do not say that DBISAM is deleting the indexes.
>>

I know, I'm just making sure that no one else gets the impression that you
are saying that.

<< I'm just wondering what happens if the .idx file is corrupted (like .dat
files sometimes can be corrupted). If DBISAM can't read the idx file then a
new empty one is created and i will not get an error message, right ???  >>

No.  DBISAM will only recreate a new empty .idx if the .idx is completely
gone (file deleted).  If the file is corrupted, then you'll most likely get
a corruption error message when DBISAM tries to open it.

--
Tim Young
Elevate Software
www.elevatesoft.com

Robert,

<< It does, in a way. If the IDX file is corrupted, DBISAM creates a new
one,  and you have lost all your indexes. >>

That is absolutely false.

<< Does not tell you about it either. Just go to dbsys, delete an idx file,
put any garbage in its place, and open the table. Look at the index
structure, it is blank. >>

Yes, with the operative part of the sentence here being "delete an idx
file".  If someone insists on doing what you just described, then they get
whatever is coming to them.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:C3862BC1-B74F-40F3-ACE1-135F4CCA3AE3@news.elevatesoft.com...
> Robert,
>
> << It does, in a way. If the IDX file is corrupted, DBISAM creates a new
> one,  and you have lost all your indexes. >>
>
> That is absolutely false.
>

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.

> << Does not tell you about it either. Just go to dbsys, delete an idx
> file, put any garbage in its place, and open the table. Look at the index
> structure, it is blank. >>
>
> Yes, with the operative part of the sentence here being "delete an idx
> file".  If someone insists on doing what you just described, then they get
> whatever is coming to them.

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.

I swear I don't understand why you get so emotional about this. 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. A
design decision. No sense starting a war over it.

Robert

Robert

Using V4.24b1 I've just tried corrupting the .idx and I get an error 12036 on trying to open the table


Roy Lambert