Hi,

I dont know if this is conincidental or not but since we have moved some
clients from V3.23 to V3.30 of client/server, we have had a number of
incidence of 'Engine Error#8965' - Index Page Buffers are corrupt in the
table 'xxx' across multiple clients.  A check in a couple of instances shows
that a repair has indeed found errors in indexes.

Has anyone else prior to Version 4, used DBISAM in a higher volume situation
using client/server V3.30?  These sort of errors are starting to worry us,
we have been running the application in Paradox for years without these
occurences of errors (yes even the dreaded Paradox index errors).

Could it be server response times?  Is DBISAM more susceptible to this than
other database engines?  Looking for some quick answers.

Thanks

Alex

Hi,

In line with the above, here is a log of the result of a repair.

Repair of table BOOKING started at 3/03/2006 4:39:13 PM...
Indexes do not match record data and are invalid, starting to fix indexes...
Error rebuilding index keys for physical record # 1172, error fixed but
physical record deleted...
Invalid indexes fixed...
Repair of table BOOKING completed at 3/03/2006 4:39:23 PM...

Questions, why does an index issue need to delete a physical record?  And is
it normal not to be asked first?  What is the most likely cause of this?
Network instability?  Is it more susceptible in DBISAM than say a Paradox
environment?

Alex

"Al VAs" <deleteprefix_alex@favour.com.au> wrote in message
news:F4801F5D-459C-4A04-A780-CDBE74F1CD20@news.elevatesoft.com...
> Hi,
>
> I dont know if this is conincidental or not but since we have moved some
> clients from V3.23 to V3.30 of client/server, we have had a number of
> incidence of 'Engine Error#8965' - Index Page Buffers are corrupt in the
> table 'xxx' across multiple clients.  A check in a couple of instances
> shows that a repair has indeed found errors in indexes.
>
> Has anyone else prior to Version 4, used DBISAM in a higher volume
> situation using client/server V3.30?  These sort of errors are starting to
> worry us, we have been running the application in Paradox for years
> without these occurences of errors (yes even the dreaded Paradox index
> errors).
>
> Could it be server response times?  Is DBISAM more susceptible to this
> than other database engines?  Looking for some quick answers.
>
> Thanks
>
> Alex
>

Alex,

<< [re deletion]... And is it normal not to be asked first?  What is the most likely cause of this? >>

I can't answer that one. Better wait for Tim...

<< Is it more susceptible in DBISAM than say a Paradox environment? >>

I do remember building, running and supporting two Paradox multi-user network
applications. It was a nightmare because of the frequent problems with index
corruption. The only solution: force all users to log out, repair, restart. Horrible.

DBISAM (in my experience so far, only up to ver 3) is way more stable.

Regards,
Dan

Al,

I would guess that if the index is unique, it would need to
either remove the data record or drop itself. I would
personally prefer the latter or a way for an index to be
marked as something like "Suspended" or "Not Maintained" or
"Repair Key Violation" so that the structure remains but the
index is not built.

Sean

Al VAs wrote:
> Hi,
>
> In line with the above, here is a log of the result of a repair.
>
> Repair of table BOOKING started at 3/03/2006 4:39:13 PM...
> Indexes do not match record data and are invalid, starting to fix indexes...
> Error rebuilding index keys for physical record # 1172, error fixed but
> physical record deleted...
> Invalid indexes fixed...
> Repair of table BOOKING completed at 3/03/2006 4:39:23 PM...
>
> Questions, why does an index issue need to delete a physical record?  And is
> it normal not to be asked first?  What is the most likely cause of this?
> Network instability?  Is it more susceptible in DBISAM than say a Paradox
> environment?
>
> Alex
>
> "Al VAs" <deleteprefix_alex@favour.com.au> wrote in message
> news:F4801F5D-459C-4A04-A780-CDBE74F1CD20@news.elevatesoft.com...
>
>>Hi,
>>
>>I dont know if this is conincidental or not but since we have moved some
>>clients from V3.23 to V3.30 of client/server, we have had a number of
>>incidence of 'Engine Error#8965' - Index Page Buffers are corrupt in the
>>table 'xxx' across multiple clients.  A check in a couple of instances
>>shows that a repair has indeed found errors in indexes.
>>
>>Has anyone else prior to Version 4, used DBISAM in a higher volume
>>situation using client/server V3.30?  These sort of errors are starting to
>>worry us, we have been running the application in Paradox for years
>>without these occurences of errors (yes even the dreaded Paradox index
>>errors).
>>
>>Could it be server response times?  Is DBISAM more susceptible to this
>>than other database engines?  Looking for some quick answers.
>>
>>Thanks
>>
>>Alex
>>
>
>
>

Alex,

<< I dont know if this is conincidental or not but since we have moved some
clients from V3.23 to V3.30 of client/server, we have had a number of
incidence of 'Engine Error#8965' - Index Page Buffers are corrupt in the
table 'xxx' across multiple clients.  A check in a couple of instances shows
that a repair has indeed found errors in indexes. >>

There is the possibility of this error with 3.30 in a higher volume
situation.  Send me an email and I will respond with a corrected version of
the dbisamen.pas unit that fixes this.

--
Tim Young
Elevate Software
www.elevatesoft.com

Alex,

<< Questions, why does an index issue need to delete a physical record? >>

Because the index is enforcing the primary key constraint and the constraint
has been violated for that record.  It cannot be kept in the table so it
must be removed.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:252A15F2-D18A-468A-9BE7-1696B46EA011@news.elevatesoft.com...
> Alex,
>
> << Questions, why does an index issue need to delete a physical record? >>
>
> Because the index is enforcing the primary key constraint and the constraint has been violated for that record.  It cannot be kept
> in the table so it must be removed.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

surely then it should be possible for the index rebuild to
create a [table_name]_index_errors table that is a structural copy
(without any indexes) to copy the deleted data to and thus
enable users to check what has been removed
(or at least dump the data to the log file)

gF

Hi Tim,

alex     AT   favourDOTcomDOTau

Thankyou muchly

Alex

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:A1683D41-4383-4309-9ACE-7BF658F6FDB9@news.elevatesoft.com...
> Alex,
>
> << I dont know if this is conincidental or not but since we have moved
> some clients from V3.23 to V3.30 of client/server, we have had a number of
> incidence of 'Engine Error#8965' - Index Page Buffers are corrupt in the
> table 'xxx' across multiple clients.  A check in a couple of instances
> shows that a repair has indeed found errors in indexes. >>
>
> There is the possibility of this error with 3.30 in a higher volume
> situation.  Send me an email and I will respond with a corrected version
> of the dbisamen.pas unit that fixes this.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Greg,

<< surely then it should be possible for the index rebuild to create a
[table_name]_index_errors table that is a structural copy (without any
indexes) to copy the deleted data to and thus enable users to check what has
been removed (or at least dump the data to the log file) >>

Sure, it's possible.  However, this type of issue is also extremely rare,
which is why we haven't implemented something like this prior.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

How long have you been aware of this.  In conversation previously when I was
asked why we were still on 3.21, I said because it was stable, and no
mention was made that Index Page Buffers could be an issue.  This seems
fairly serious especially since a rebuild seems to delete actual data on
occasion.  Anyway we are desperate for this new dbisamem.pas unit to fix
this critical issue.  Our prgrammer is going on leave soon and we need to
resolve.

Also are there any other potential issues you are aware of in a high volume
environment?

Regards

Alex

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:A1683D41-4383-4309-9ACE-7BF658F6FDB9@news.elevatesoft.com...
> Alex,
>
> << I dont know if this is conincidental or not but since we have moved
> some clients from V3.23 to V3.30 of client/server, we have had a number of
> incidence of 'Engine Error#8965' - Index Page Buffers are corrupt in the
> table 'xxx' across multiple clients.  A check in a couple of instances
> shows that a repair has indeed found errors in indexes. >>
>
> There is the possibility of this error with 3.30 in a higher volume
> situation.  Send me an email and I will respond with a corrected version
> of the dbisamen.pas unit that fixes this.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>