Hi,

Have just been advised by support that a number of our clients are
experiencing index issues requiring rebuilds.  The table which is most
commonly affected is the most commonly used by a number of users at one
time.  Our largest client has maybe 10-12 people accessing at a given time.
What causes these index issues, and how can they be reduced?  I was actualy
hoping that indexes issues would go away when we moved from Paradox, where
at the moment it seems to be on the increase.

Does anyone have any suggestions for rebuilding indexes (so that users dont
have to rely on us).

We are using V3.30 of DBISAM and all these clients are running
client/server - which also makes me wonder why so many index issues.

Thanks

Alex

Alex,

<< Have just been advised by support that a number of our clients are
experiencing index issues requiring rebuilds.  The table which is most
commonly affected is the most commonly used by a number of users at one
time.  Our largest client has maybe 10-12 people accessing at a given time.
What causes these index issues, and how can they be reduced?  I was actualy
hoping that indexes issues would go away when we moved from Paradox, where
at the moment it seems to be on the increase.

Does anyone have any suggestions for rebuilding indexes (so that users dont
have to rely on us).

We are using V3.30 of DBISAM and all these clients are running
client/server - which also makes me wonder why so many index issues. >>

Did I send you the fixed dbisamen.pas for 3.30 that fixes the index buffer
corruption issue ?

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:7AFE317C-E3BC-4203-A140-C36EA24527FB@news.elevatesoft.com...
>
> Did I send you the fixed dbisamen.pas for 3.30 that fixes the index buffer
> corruption issue ?
>

What is this?

Robert, another user of 3.30

Robert,

<< What is this? >>

It's an unofficial update that fixes an issue where you could get #8965 Page
buffers corrupt errors.  Send me an email if you want it, and I'll reply
with the corrected unit.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim

Yes we've implemented that and from what I can tell, this particular issue
has not reared its head very much.  The sort of index issues that are
happening, seem to usually not stop the user from working, its just that
when they do a fitler for example, it doesnt come up with expected results.
Then our investigation finds that the index has errors and needs to be
rebuilt.  And the probem is then resolved.  The predominant table we appear
to be having issues with, does have quite a few indexes on it, 12 to be
exact.  So my questions still remain, specially:

> Does anyone have any suggestions for rebuilding indexes (so that users
> dont have to rely on us).

Thanks

Alex
"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:7AFE317C-E3BC-4203-A140-C36EA24527FB@news.elevatesoft.com...
> Alex,
>
> << Have just been advised by support that a number of our clients are
> experiencing index issues requiring rebuilds.  The table which is most
> commonly affected is the most commonly used by a number of users at one
> time.  Our largest client has maybe 10-12 people accessing at a given
> time. What causes these index issues, and how can they be reduced?  I was
> actualy hoping that indexes issues would go away when we moved from
> Paradox, where at the moment it seems to be on the increase.
>
> Does anyone have any suggestions for rebuilding indexes (so that users
> dont have to rely on us).
>
> We are using V3.30 of DBISAM and all these clients are running
> client/server - which also makes me wonder why so many index issues. >>
>
> Did I send you the fixed dbisamen.pas for 3.30 that fixes the index buffer
> corruption issue ?
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Just for some further information, just went through our support logs today,
and for this week alone we've had no less than 6 clients who have
experienced index issues, 5 on the predominant table.  We need some clues,
something we can start with as its getting a little out of hand.  Could
pessimistic locking have anything to do with it?  How do you handle updates
of indexes. at what stage does this happen?

Thanks

Alex

"Al Vas" <noreply@noreply.com> wrote in message
news:7D9AB07A-1FBA-4909-8F60-D352EFEEA8F9@news.elevatesoft.com...
> Hi Tim
>
> Yes we've implemented that and from what I can tell, this particular issue
> has not reared its head very much.  The sort of index issues that are
> happening, seem to usually not stop the user from working, its just that
> when they do a fitler for example, it doesnt come up with expected
> results. Then our investigation finds that the index has errors and needs
> to be rebuilt.  And the probem is then resolved.  The predominant table we
> appear to be having issues with, does have quite a few indexes on it, 12
> to be exact.  So my questions still remain, specially:
>
>> Does anyone have any suggestions for rebuilding indexes (so that users
>> dont have to rely on us).
>
> Thanks
>
> Alex
> "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
> news:7AFE317C-E3BC-4203-A140-C36EA24527FB@news.elevatesoft.com...
>> Alex,
>>
>> << Have just been advised by support that a number of our clients are
>> experiencing index issues requiring rebuilds.  The table which is most
>> commonly affected is the most commonly used by a number of users at one
>> time.  Our largest client has maybe 10-12 people accessing at a given
>> time. What causes these index issues, and how can they be reduced?  I was
>> actualy hoping that indexes issues would go away when we moved from
>> Paradox, where at the moment it seems to be on the increase.
>>
>> Does anyone have any suggestions for rebuilding indexes (so that users
>> dont have to rely on us).
>>
>> We are using V3.30 of DBISAM and all these clients are running
>> client/server - which also makes me wonder why so many index issues. >>
>>
>> Did I send you the fixed dbisamen.pas for 3.30 that fixes the index
>> buffer corruption issue ?
>>
>> --
>> Tim Young
>> Elevate Software
>> www.elevatesoft.com
>>
>>
>
>

Alex,

<< Yes we've implemented that and from what I can tell, this particular
issue has not reared its head very much.  The sort of index issues that are
happening, seem to usually not stop the user from working, its just that
when they do a fitler for example, it doesnt come up with expected results.
Then our investigation finds that the index has errors and needs to be
rebuilt.  And the probem is then resolved.  The predominant table we appear
to be having issues with, does have quite a few indexes on it, 12 to be
exact.  So my questions still remain, specially:

Does anyone have any suggestions for rebuilding indexes (so that users dont
have to rely on us). >>

The only way to do so is via the RepairTable method.  As for the issue at
hand - the only thing I can recommend at this time is to upgrade to V4.  It
definitely does not have any issues like this, and unfortunately, I just
don't have the time right now to spend a lot of time trying to diagnose any
3.x issues right now due to the ElevateDB workload.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

Upgrading to V4 is not an option.  We plan on moving to V5 once it is out
and stable, so maybe at least 3-6 months from when you release it.  For
obvious reasons there is no point us upgrading to 4 and then 5.  In the
meantime we have to manage these issues as best we can.  Surely you have
some historical information on this type of issue.  I cant believe that
no-one else has experienced this type of issue in the past.  Maybe if we
find out more specifically what sort of index errors are occurring, or offer
samples of the corrupted tables to at least give some direction?

Alex

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:9E0A4410-BBB3-48BC-8957-4312527CF014@news.elevatesoft.com...
> Alex,
>
> << Yes we've implemented that and from what I can tell, this particular
> issue has not reared its head very much.  The sort of index issues that
> are happening, seem to usually not stop the user from working, its just
> that when they do a fitler for example, it doesnt come up with expected
> results. Then our investigation finds that the index has errors and needs
> to be rebuilt.  And the probem is then resolved.  The predominant table we
> appear to be having issues with, does have quite a few indexes on it, 12
> to be exact.  So my questions still remain, specially:
>
> Does anyone have any suggestions for rebuilding indexes (so that users
> dont have to rely on us). >>
>
> The only way to do so is via the RepairTable method.  As for the issue at
> hand - the only thing I can recommend at this time is to upgrade to V4.
> It definitely does not have any issues like this, and unfortunately, I
> just don't have the time right now to spend a lot of time trying to
> diagnose any 3.x issues right now due to the ElevateDB workload.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Alex,

<< Upgrading to V4 is not an option.  We plan on moving to V5 once it is out
and stable, so maybe at least 3-6 months from when you release it.  For
obvious reasons there is no point us upgrading to 4 and then 5.  In the
meantime we have to manage these issues as best we can.  Surely you have
some historical information on this type of issue.  I cant believe that
no-one else has experienced this type of issue in the past.  Maybe if we
find out more specifically what sort of index errors are occurring, or offer
samples of the corrupted tables to at least give some direction? >>

I don't have any more information than you do.  It's not something that was
reported when 3.x was being updated, nor has it been reported since.  And as
I stated before, I unfortunately don't have the time to dedicate to pursuing
this type of issue with 3.x right now.  These types of issues literally can
take weeks to track down.

We had some index issues in 4.x that might be similar, but I can't say for
sure without some type of reproduction of the issue.  If I had the time, I
could rig up 3.x into the 4.x test suite and give it a run.  But, that would
take more time than I have right now.

--
Tim Young
Elevate Software
www.elevatesoft.com