Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 22 total |
Corruption more likely when two apps access same DB? |
Tue, Jun 1 2010 6:25 AM | Permanent Link |
Dominique Willems | After quite some years of experience with DBISAM V3, I keep noticing
that users who run my app on a system that has two apps accessing the same DB simultaneously, suffer more data corruption than others. My questions: 1) is there anything I can do in V3 to avoid this? 2) would V4 solve these issues? Thanks, Dom |
Tue, Jun 1 2010 6:44 AM | Permanent Link |
Dominique Willems | Additional question:
Does a RepairTable imply a LockTable? Ie. do all apps suspend access to the table being repaired by another app? |
Tue, Jun 1 2010 8:15 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Dominique
RepairTable requires exclusive access to the table. Roy Lambert [Team Elevate] |
Tue, Jun 1 2010 8:20 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Dominique
1. Do you have any information about what the corruption is and what's causing it, what the PC configuration & OS is? 2. Try FlushBuffers after posting data. That should mean its written to disk and safe. Roy Lambert [Team Elevate] |
Tue, Jun 1 2010 9:44 AM | Permanent Link |
Dominique Willems | Roy Lambert wrote:
> 1. Do you have any information about what the corruption is and > what's causing it, what the PC configuration & OS is? No, it varies. And PC and OS too. > 2. Try FlushBuffers after posting data. That should mean its written > to disk and safe. Yes, that's what I'm doing. I'm guessing a RepairTable while another app is accessing the data might be one of the reasons. |
Tue, Jun 1 2010 10:06 AM | Permanent Link |
Robert Kaplan | "Dominique Willems" <dominique.willems@gmail.com> wrote in message news:7610B6DA-BDFF-438A-9E65-4DC1A7734F1D@news.elevatesoft.com... > > Yes, that's what I'm doing. I'm guessing a RepairTable while another > app is accessing the data might be one of the reasons. The repair will not start if another app is accessing the table (at least in the current version of DBISAM). Flushbuffers and such are only useful if you suspect hardware problems, or if the data is absolutely critical. As far as your program corrupting the data, it is possible. Most cases I've had have been caused by multi-row updates not wrapped in a transaction. Robert |
Tue, Jun 1 2010 10:16 AM | Permanent Link |
Dominique Willems | Robert K wrote:
> The repair will not start if another app is accessing the table (at > least in the current version of DBISAM). Is this also the case in version 3? Tim? |
Tue, Jun 1 2010 10:25 AM | Permanent Link |
Robert Kaplan | "Dominique Willems" <dominique.willems@gmail.com> wrote in message news:52E82E91-9961-45A3-A8F3-08E2CA1A2FEA@news.elevatesoft.com... > Robert K wrote: >> The repair will not start if another app is accessing the table (at >> least in the current version of DBISAM). > > Is this also the case in version 3? Tim? Try with DBSYS, open the table and then try to do a repair. R |
Tue, Jun 1 2010 10:47 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Dominique
>> The repair will not start if another app is accessing the table (at >> least in the current version of DBISAM). > >Is this also the case in version 3? Tim? I'm pretty sure is was that way back in V2 as well. Repairing like optimising is something that can not be done with the table being modified at the same time. Roy Lambert [Team Elevate] |
Tue, Jun 1 2010 11:22 AM | Permanent Link |
Dominique Willems | Roy Lambert wrote:
> Repairing like > optimising is something that can not be done with the table being > modified at the same time. Can or won't? |
Page 1 of 3 | Next Page » | |
Jump to Page: 1 2 3 |
This web page was last updated on Tuesday, April 30, 2024 at 03:55 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |