Hi Team,
   I have taken the cautionary route of adding xxxxx.FlushBuffers; into all the relevant AfterPost events.
   Is there any down side to this?
   What other circumstances should it be and/or not be used?
Regards,
Ian

Ian

>    I have taken the cautionary route of adding xxxxx.FlushBuffers; into all the relevant AfterPost events.
>    Is there any down side to this?
>    What other circumstances should it be and/or not be used?

There is a major downside - SPEED. Buffers are there for a reason - its a lot faster to write into RAM than down onto disk. I'm also never sure which bit of flushing from who (Tim or MS or LAN) actually gets things onto disk.

Roy

Hi Roy,
   ATT I am prepared to accept the speed penalty.
Regards,
Ian

Ian


>    ATT I am prepared to accept the speed penalty.

What's going wrong that you think you need it? Have you tested the speed differential in real life? Way back I had a multi-page app where I flushed buffers between each page movement. I ended up making it optional and most people turned it off because the delay was most annoying.

Roy

Hi Roy,
   Given the flakiness of the Customer's network, I just want to make sure every post is physically written asap.
   The Customer came from a DOS App to this and doesn't really know any difference aside from the new app being faster
and easier to use than the old.

Regards,
Ian

Ian,

<< Given the flakiness of the Customer's network, I just want to make sure every post is physically written asap. >>

Using FlushBuffers isn't going to help with network issues *at all*.  You're just going to make the application slower than it needs to be.  In fact, you will make writes to disk slower and will incur more network roundtrips for the flush calls, which may end up making the network situation worse, not better.

The only way to really resolve network issues, as they relate to direct file-sharing access to the database and the resultant data integrity issues that can be involved, is to using remote sessions with the ElevateDB Server.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Ian,
>
> << Given the flakiness of the Customer's network, I just want to make sure every post is physically written asap. >>
>
> Using FlushBuffers isn't going to help with network issues *at all*.  You're just going to make the application
> slower than it needs to be.  In fact, you will make writes to disk slower and will incur more network roundtrips for
> the flush calls, which may end up making the network situation worse, not better.
>
> The only way to really resolve network issues, as they relate to direct file-sharing access to the database and the
> resultant data integrity issues that can be involved, is to using remote sessions with the ElevateDB Server.
>
> Tim Young
> Elevate Software
> www.elevatesoft.com