Icon View Thread

The following is the text of the current message along with any replies.
Messages 31 to 39 of 39 total
Thread ForceBufferFlush is extremely slow on Vista
Wed, Mar 5 2008 10:31 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 AMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 PMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 PagePage 4 of 4
Jump to Page:  1 2 3 4
Image