Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 10 of 15 total |
Index Page Buffers Corrupt |
Fri, Mar 3 2006 12:20 AM | Permanent Link |
"Al VAs" | 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 |
Fri, Mar 3 2006 2:34 AM | Permanent Link |
"Al VAs" | 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 > |
Fri, Mar 3 2006 3:55 AM | Permanent Link |
Dan Rootham | 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 |
Fri, Mar 3 2006 9:26 AM | Permanent Link |
Sean McCall | 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 >> > > > |
Fri, Mar 3 2006 10:48 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Fri, Mar 3 2006 10:49 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Sat, Mar 4 2006 8:20 PM | Permanent Link |
"GregF" | "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 |
Mon, Mar 6 2006 4:54 AM | Permanent Link |
"Al Vas" | 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 > > |
Mon, Mar 6 2006 11:43 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Tue, Mar 7 2006 2:07 AM | Permanent Link |
"Al VAs" | 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 > > |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |