Hello,

I've read in the DBISAM manual about Flushbuffers:
"If the table or query result set is opened shared, then FlushBuffers only instructs the operating system to flush all writes to disk since shared datasets do not cache any writes."

When using multiuser file access to a DBISAM table (no server), I'm wondering if it makes any difference to call Flushbuffers or not to call it in the afterpost event?

Is it recommended to use Flushbuffers in a multiuser environment?

Thank you and best wishes,
Markus

Markus Gnam

<<
Is it recommended to use Flushbuffers in a multiuser environment?
>>
Are you using transactions ? If so, then it is a default for commit. If you don´t want FlushBuffers then call Commit(False).

If you do not have a server, not using FlushBuffers will gain performance but you are with more risk to corruption.

Eduardo

Hello Eduardo,

thank you! I don't use Transactions.

Data integrity is very important for me. Performance is very important for me too, but until now I haven't experienced big differences when using Flushbuffers or not using it.

However, when iterating through a dataset with a while loop, calling Flushbuffers in the afterpost event seems to slow performance signifcantly down. Therefore, when executing while loops I don't call Flushbuffers (of course in this case this is a single user environment with exclusive opening of the table).

Best wishes,
Markus

Hello Eduardo,

thank you! I don't use Transactions.

Data integrity is very important for me. Performance is very important for me too, but until now I haven't experienced big differences when using Flushbuffers or not using it.

However, when iterating through a dataset with a while loop and assigning values to a field, calling Flushbuffers in the afterpost event seems to slow performance signifcantly down. Therefore, when executing while loops I don't call Flushbuffers (of course in this case this is a single user environment with exclusive opening of the table).

Best wishes,
Markus

Markus


I would not advise calling FlushBuffers after every table post in any app.

When I used DBISAM I did at one time use FlushBuffers in a multiuser filesharing environment but it really did slow things down. What I ended up doing was calling FlushBuffers at "convenient" points. In the case of one app it was a tabbed forms approach so I called it every time the user switched from one tab (read form) to another.

Its worth it if you have a slightly fragile network (if you have a very fragile network you shouldn't be doing anything) and adding in some recovery tools (repair table capability at the very least) just in case.

Roy Lambert

Thank you, Roy.

I will observe the speed in multiuser filesharing environment the next weeks. If performance is too slow I'm going to switch back to not using FlushBuffers or using it rarely like you suggested.

Best wishes,
Markus

Markus Gnam

My suggestion is:

Start using Transactions and let DBISAM handle FlushBuffers for you. This is the best solution and you will check a improvement of performance. As Roy indicated the use of FlushBuffers for each table post will slow down a lot. Just make sure all table updades are enclosured by a transaction and corruption is zero or near zero.

Eduardo

Eduardo


>Start using Transactions and let DBISAM handle FlushBuffers for you. This is the best solution and you will check a improvement of performance. As Roy indicated the use of FlushBuffers for each table post will slow down a lot. Just make sure all table updades are enclosured by a transaction and corruption is zero or near zero.

I don't know what your take is but if moving to transactions I'd also suggest moving away from data bound controls, and from pessimistic to optimistic locking so that all the data can be gathered together and the transaction is kept short.

I didn't and don't use transactions much, and where I do its more for batch processes than individual posts.

Roy

Hello Eduardo,

I have never used transactions before and as Roy mentioned, I'm not sure if individual posts are suitable for transaction use. I simply use a DBISAMTable bound to a DBGrid control. When the user changes a value in the DBGrid, it gets posted automatically when he goes to the next record. I don't use any SQL statements. I use a lot of assignments in the BeforePost event (I also evaluate the AfterEdit event for creating an Undo history). I've planned to use the AfterPost event for calling Flushbuffers. I'm unsure where to start a transaction. The AfterPost event will most probably be too late for starting a transaction.

Thank you both, Eduardo and Roy.
Best wishes,
Markus

Markus


Just to go back to the beginning - why did you consider using FlushBuffers to start with.were you having problems with corruption or what?

Roy Lambert