Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 31 to 39 of 39 total |
ForceBufferFlush is extremely slow on Vista |
Wed, Mar 5 2008 10:31 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Mauricio,
<< Well, I have read the links and sincerely I have not found such evidence in nowhere. Anyway, corrupted tables are consuming almost 50% of our technical support team. >> Are these single-user installations or multi-user installations ? -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Mar 5 2008 10:39 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Sam,
<< b) The ForceFlushBuffers session property: We found, when testing on XP, that our TRANSACTIONAL performance was almost unaffected. Our transaction time is ~1 second per, of which a small small fraction is actual DBISAM overhead. So we were good with this. >> That's because transactions buffer any updates until commit time, and a buffer flush is, by default, automatically done after a transaction commit. << c) The reason we used ForceFlushBuffers at the session level is that some users were hitting our software so hard, that our software would hang, and when it was terminated, the DBISAM data would be damaged. By using ForceFlushBuffers, this corruption problem was solved. >> What do you mean by "our software would hang" ? Hang waiting on database operations ? If so, how many users are you talking about ? << 1) For the DBISAM guys to explain to us all at a low level "Property X in DBISAM is behaving differently (slower) on Vista, and here is why" We don't have this yet... oh well. >> I can't tell you why because I don't have access to the Vista source code, nor the expertise to properly evaluate it even if I did. If you want the "why" of it, contact the MS file system developers and ask them directly. If you expect me to spend a couple of days tracking this down with the MS developers personally, I'm afraid that it simply isn't in the cards right now. Frankly, this whole thread is bordering on the absurd. I, and others, have continuously given you the information that you need to resolve this issue in your application, yet you seem to ignore it and return right back to the same starting point with your posts. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Mar 7 2008 10:53 AM | Permanent Link |
Mauricio Campana Nonino | Tim Young,
<<Are these single-user installations or multi-user installations ?>> Both, but many of the times, the problem ocurrs in a multi-user enviroment. Mauricio Campana Nonino Nonino Software |
Fri, Mar 7 2008 11:15 AM | Permanent Link |
Mauricio Campana Nonino | Robert
>>What are the errors? DBISAM_HEADERCORRUPT (8961) and DBISAM_INDEXCORRUPT (8965) >>What is the DBISAM version? 4.25 Build 5 >>How do you fix them? "RepairTable" does the job, but many times we have to manually delete lots of "garbage" records. Mauricio Campana Nonino Nonino Software |
Mon, Mar 10 2008 3:46 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Mauricio,
< Both, but many of the times, the problem ocurrs in a multi-user enviroment. >> Is the file server being used a dedicated file server, or is it also a workstation ? It it's the latter, then that would account for such issues. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Mar 10 2008 3:57 PM | Permanent Link |
Mauricio Campana Nonino | Tim Young,
>>Is the file server being used a dedicated file server, or is it also a >>workstation ? It it's the latter, then that would account for such issues. It's the latter. One of the bad things is to delete the garbage records. I am seriouly thinking to change the "RepairTable" method to automatically delete garbage records based upon record checksum. Mauricio Campana Nonino Nonino Software |
Mon, Mar 10 2008 6:44 PM | Permanent Link |
"Gregory Sebastian" | Hello Mauricio,
<<I am seriouly thinking to change the "RepairTable" method to automatically delete garbage records based upon record checksum>> This is what I do too. After calling RepairTable, more often or not, there are a lot of garbaged records added on at the start and end of the corrupted tables. Previously, I had to manually delete each and every corrupted record using Database System Utility. I expanded my RepairTable utility to check each record for validity and delete garbaged records. This saves you from having to do it manually. It won't take long to implement this. Data corruption in our case is low. But when it does usually occur in our case its usually because of sudden power outages or to a lesser extent, loss of network connectivity when used in file sharing. Data corruption in larger network enviroments can be reduced by simply using C/S connections instead of file sharing. Regards Gregory Sebastian |
Tue, Mar 11 2008 4:35 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Mauricio,
<< It's the latter. One of the bad things is to delete the garbage records. I am seriouly thinking to change the "RepairTable" method to automatically delete garbage records based upon record checksum. >> Well, one thing to look into is getting them to move to at least having a dedicated file server, even if it's a tiny little network file server appliance. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Mar 12 2008 3:30 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
Freecom Datatank Gateway - 1Tb operating in raid1 cost £209+vat from Viking Direct Nice little box after I sent the first one back and wrote a utility to log Windows PCs on at start up. Roy Lambert |
« Previous Page | Page 4 of 4 | |
Jump to Page: 1 2 3 4 |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |