Hi Tim,

Our current environment: DBISam 4.25b3, running via 'local' mode with
various users.

We're running the same app, via the same 'local' mode with various users at
other sites. This is the only site that's causing us grief.

We keep having corruption issues on a particular table (sometimes two) at
this one site only. I'm 99% sure that it's the environment that DBISam is
working in, but wanted to run a few things by you, just incase you or
someone else may be able to throw me a few ideas.

We're getting various kinds of corruptions (from indexes being out of date,
to errors about corrupt blobs, and page buffers). Sorry - I've been slack
and don't have the exact error messages on me at present, but they seem to
vary.

One of the interesting things I have noticed, is occasionally, if I do an
Optimize table, and then immediately after I do a verify table, it has
reported errors on the table I've just Optimized. (Not reproduceable, but
happens from time to time).

I am running the repair/verify/optimize from a different machine to where
the file is located.

My first question is - during an optimize, it's my understanding that a
brand new file is created - which should ignore (or at least not copy) any
corrupt data from the original table, if corrupt data exists (or at least
raise an exception). Is this true?

If that is true, then my understanding would be that an optimized table
should be free from defects, unless the corruption was caused by a fault
while writing the 'new' table across the network to the hard drive?

If that's the case, I'm going to start my focus at the actual network
connection, or the file server where the data resides (being a linux box). I
personally don't have much access to this clients system as it's maintained
by another IT person who's extremely concerned with security issues which
makes it a little hard for me to diagnose myself (as well as me not having a
limited understanding as to the setup of the whole system), so I'm thinking
of moving the data to a 'less secure' location so I can work with different
possibilities there. (And at least have same machine local access to the
data without having to go across a network cable to repair or rebuild
tables).

Another thought - are their any tricks or pot holes that I should watch out
for when accessing the data on a linux smb server via a windows machine in
'local' mode? (ie, wierd switches on the linux box that I should be turning
off/on) that I may be able to pass on?

It's late, and I'm rambling. In short - can anyone comment on the above,
or make any other suggestions as to how I could try and diagnose this
situation, or reduce the risk?

FYI: I've tried forcebufferflush with the session component also to try and
increase stability, but has not helped, which has me thinking possible
network fault or hardware/software fault at the file server end.

Thanks in Advance.

Adam.

Adam,

<< One of the interesting things I have noticed, is occasionally, if I do an
Optimize table, and then immediately after I do a verify table, it has
reported errors on the table I've just Optimized. (Not reproduceable, but
happens from time to time). >>

Did you verify the table beforehand to ensure that it wasn't corrupted prior
to the Optimize ?

<< My first question is - during an optimize, it's my understanding that a
brand new file is created - which should ignore (or at least not copy) any
corrupt data from the original table, if corrupt data exists (or at least
raise an exception). Is this true? >>

Yes, and no.  It does do a copy, but it depends upon what the corruption is
in the source as to whether the corruption would carry over or not.

<< If that is true, then my understanding would be that an optimized table
should be free from defects, unless the corruption was caused by a fault
while writing the 'new' table across the network to the hard drive? >>

I would not assume that an optimized table is 100% free from defects, no.
The only way to determine 100% that is not the case is to do a verify or
repair.

<< Another thought - are their any tricks or pot holes that I should watch
out for when accessing the data on a linux smb server via a windows machine
in 'local' mode? (ie, wierd switches on the linux box that I should be
turning off/on) that I may be able to pass on? >>

You'll have to check out the Samba support avenues for this, but my
understanding is that the latest incarnations work just fine.

<< FYI: I've tried forcebufferflush with the session component also to try
and increase stability, but has not helped, which has me thinking possible
network fault or hardware/software fault at the file server end.  >>

It's possible.  It could also just be an improper shutdown issue.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> << One of the interesting things I have noticed, is occasionally, if I do
> an Optimize table, and then immediately after I do a verify table, it has
> reported errors on the table I've just Optimized. (Not reproduceable, but
> happens from time to time). >>
>
> Did you verify the table beforehand to ensure that it wasn't corrupted
> prior to the Optimize ?

Yes. I actually repaired the table first, then verified it, and then
optimized it. How it came about was that after I verified the table I
thought 'maybe their is still a corruption that the verify hasn't picked up
on', so chose to do a rebuild (via optimisation instead).

> << My first question is - during an optimize, it's my understanding that a
> brand new file is created - which should ignore (or at least not copy) any
> corrupt data from the original table, if corrupt data exists (or at least
> raise an exception). Is this true? >>
>
> Yes, and no.  It does do a copy, but it depends upon what the corruption
> is in the source as to whether the corruption would carry over or not.
>
> I would not assume that an optimized table is 100% free from defects, no.
> The only way to determine 100% that is not the case is to do a verify or
> repair.

So, after doing a repair (including indexes), I should be confident that it
is the best way to make sure a table is not corrupt, and if the repair is
successful, and subsequent verifies say that the table is OK, then I'm
pretty right? (Or is their still a possibility that somewhere, something
dark is lurking within a table/index).

> << FYI: I've tried forcebufferflush with the session component also to try
> and increase stability, but has not helped, which has me thinking possible
> network fault or hardware/software fault at the file server end.  >>
>
> It's possible.  It could also just be an improper shutdown issue.

That is one of the things that we've been looking at. (And I was pretty
convinced on, until I did the repair -> verify -> optimize.) I've actually
noticed that it's not the 'same' table each time, but happens on various
tables. It appears as though it's the same tables because they're the most
common. (However, they are also the largest by a significant difference),
which makes sence.

Thanks for your help Tim!

Cheers

Adam.

Adam,

<< Yes. I actually repaired the table first, then verified it, and then
optimized it. How it came about was that after I verified the table I
thought 'maybe their is still a corruption that the verify hasn't picked up
on', so chose to do a rebuild (via optimisation instead). >>

If you have a table that reports corruption after an optimization, please
send it to me.  I haven't seen or heard of any such thing ever with DBISAM.

<< So, after doing a repair (including indexes), I should be confident that
it is the best way to make sure a table is not corrupt, and if the repair is
successful, and subsequent verifies say that the table is OK, then I'm
pretty right? (Or is their still a possibility that somewhere, something
dark is lurking within a table/index). >>

No, a repair will ensure that a table and its indexes and BLOB data is 100%
free from structural defects.  You could still have junk data in some of the
columns, however.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> If you have a table that reports corruption after an optimization, please
> send it to me.  I haven't seen or heard of any such thing ever with
> DBISAM.

Shall do. (I've just got to get it to replicate the program again first)

> << So, after doing a repair (including indexes), I should be confident
> that it is the best way to make sure a table is not corrupt, and if the
> repair is
> successful, and subsequent verifies say that the table is OK, then I'm
> pretty right? (Or is their still a possibility that somewhere, something
> dark is lurking within a table/index). >>
>
> No, a repair will ensure that a table and its indexes and BLOB data is
> 100% free from structural defects.  You could still have junk data in some
> of the columns, however.

Ah - yep, that's what I was meaning. (What I was wanting to verify was that
once a table is repaired, their's no possibility of their still being
structual problems within the table, that will cause it to corrupt more
easily again).

Thanks & Regards

Adam.

Adam H. wrote:

>>it's maintained
>>by another IT person who's extremely concerned with security issues

If he is paranoid as you say does he have Norton AV/Internet
Security running? It can sometimes screw up (other 3rd party) database
files that are open during a scan. I'm not sure whether DbIsam is
affected by Norton or not, but it's worth looking into.

Sam

Hi Sam,

> If he is paranoid as you say does he have Norton AV/Internet Security
> running? It can sometimes screw up (other 3rd party) database files that
> are open during a scan. I'm not sure whether DbIsam is affected by Norton
> or not, but it's worth looking into.

Good thought. Unfortuantly though, he doesn't. They're using another
antivirus software package that I'm familiar with (and use at other site)
that causes no problems.

Best Regards

Adam.