Hello Robert, I'd argue that it's impossible to be ACID compliant with crappy IDE drives specifically because they don't support the ability to bypass the drive's built in cache. Whether you use "FlushFileBuffers" or FILE_FLAG_WRITE_THROUGH, you don't know that the drive actually wrote the data to disk. That's what I also got out of the link you provided. IDE/SATA drives, you can't actually know if the data is flushed to "oxide" whereas with SCSI you can.
That being the case, and because Microsoft uses this flag with their own enterprise database, leads me to believe it would be worth investigating. C Saturday, January 28, 2006, 10:59:22 PM, you wrote: >> -----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. RS> DRH is right. That flag allows the hardware (if it supports it) to bypass RS> the caches, but doesn't always work. On IDE harddrives, that flag only RS> causes the data to go into the HDD cache and doesn't confirm that the data RS> was actually physically written. If you can't guarantee it was written, you RS> can't be ACID compliant. The MSDN docs on this flag have this disclaimer: RS> "However, not all hardware supports this write-through capability" RS> See this thread: RS> http://groups.google.com/group/microsoft.public.win32.programmer.kernel/brow RS> se_frm/thread/4590ed3a4133828f/406cfb3a9deae044?lnk=st&q=FILE_FLAG_WRITE_THR RS> OUGH&rnum=2&hl=en RS> In it, Karan Mehra (MS) explains the difference between FlushFileBuffers() RS> and FILE_FLAG_WRITE_THROUGH -- and they are rather important differences. RS> What you need to do is evaluate your program to see if perhaps it can be RS> rearchitected to insert multiple rows at a time rather than doing a bunch of RS> singular inserts. If you could queue all write to a single thread, and the RS> thread waited until it had 10-20 items before it flushed them to the DB, RS> you'd gain a lot of performance back. RS> Robert -- Best regards, Teg mailto:[EMAIL PROTECTED]
