> -----Original Message----- > From: Nono BEZMan [mailto:[EMAIL PROTECTED] > > My point was that there is light for windows users, if > this > FILE_FLAG_WRITE_THROUGH flag is added to the code. > Otherwise, it seems that > FlushFileBuffers really hinders SLQite to a point it > becomes unusable. '7 > Inserts per seconds' on a brand new AMD64 3500+ with > SATA drives is extremely > low, and this could be fixed by using this option, > IMO.
DRH is right. That flag allows the hardware (if it supports it) to bypass the caches, but doesn't always work. On IDE harddrives, that flag only causes the data to go into the HDD cache and doesn't confirm that the data was actually physically written. If you can't guarantee it was written, you can't be ACID compliant. The MSDN docs on this flag have this disclaimer: "However, not all hardware supports this write-through capability" See this thread: http://groups.google.com/group/microsoft.public.win32.programmer.kernel/brow se_frm/thread/4590ed3a4133828f/406cfb3a9deae044?lnk=st&q=FILE_FLAG_WRITE_THR OUGH&rnum=2&hl=en In it, Karan Mehra (MS) explains the difference between FlushFileBuffers() and FILE_FLAG_WRITE_THROUGH -- and they are rather important differences. What you need to do is evaluate your program to see if perhaps it can be rearchitected to insert multiple rows at a time rather than doing a bunch of singular inserts. If you could queue all write to a single thread, and the thread waited until it had 10-20 items before it flushed them to the DB, you'd gain a lot of performance back. Robert
