Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 19 total |
Global FlushBuffers() - how do I do that? |
Fri, Mar 21 2008 2:28 PM | Permanent Link |
timjones | I want to modify our application so instead of the global
Session.ForceBufferFlush = TRUE we flush buffers only after a block of database operations (bunch of inserts or bunch of updates). We are using application framework that creates new DBISAMQuery object for each SQL operation. So the sequence is - Create DBISAMQuery - Execute SQL - Destroy DBISAMQuery - repeat 1000 times... I need a function that can flush buffers without having reference to the DBISAMQuery or DBISAMTable. How can I implement global ForceBuffers() function that would flush all "unflushed" buffers to disk? |
Fri, Mar 21 2008 3:18 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | << I need a function that can flush buffers without having reference to the DBISAMQuery or DBISAMTable. How can I implement global ForceBuffers() function that would flush all "unflushed" buffers to disk? >> There isn't one at this time. It's something that I can put on the enhancements list for the next minor release, however. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Mar 21 2008 3:33 PM | Permanent Link |
"Robert" | "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:F6CA30C2-2C2F-4BBC-B6AE-1D94A5D179A5@news.elevatesoft.com... > > << I need a function that can flush buffers without having reference to > the DBISAMQuery or DBISAMTable. How can I implement global ForceBuffers() > function that would flush all "unflushed" buffers to disk? >> > > There isn't one at this time. It's something that I can put on the > enhancements list for the next minor release, however. > Tim, what would happen if you do a database.starttransaction followed immediately by a database.commit(true)? Robert |
Fri, Mar 21 2008 4:05 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | timjones
Whilst waiting for Tim why not think of altering your approach? Rather than creating a fresh query build a script, wrap in a transaction sling the resultant sql at one query and call flushbuffers at the end. Should also be faster than your current approach as a bonus. Roy Lambert |
Fri, Mar 21 2008 4:28 PM | Permanent Link |
timjones | > Whilst waiting for Tim why not think of altering your approach?
> Rather than creating a fresh query build a script, wrap in a transaction sling the resultant sql at one query and call flushbuffers at the end. Sounds good on paper, but would not work in real life Rewriting a chunk of large 3rd party application framework is not very good ROI for our time. We use tools like DBISAM and application frameworks so our life gets easier and not more complex |
Sat, Mar 22 2008 6:05 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | timjones
>Rewriting a chunk of large 3rd party application framework is not very good ROI for our >time. It is if it prevents errors and stops customers complaining >We use tools like DBISAM and application frameworks so our life gets easier and not >more complex Without seeing your code obviously I can't comment on how much more complex it would get but I am surprised. My thoughts were based on the fact that you are creating the query. This means that you must be assigning the sql code to its sql property. so rather than - Create DBISAMQuery - Execute SQL - Destroy DBISAMQuery - repeat 1000 times... You'd have create stringlist add sql to stringlist repeat 1000 times assign sql to query execute query flushbuffers destroy query destroy stringlist Roy Lambert |
Sat, Mar 22 2008 11:28 AM | Permanent Link |
Sean McCall | Looking at the source code it looks like it might work to toggle
ForceFlushBuffers right before the last query. So, if you want to force fluah every 300 times: var AFlushCount: Integer; AFlushInterval: Integer; ResetFlushBuffers(300); {every 300) for I := 1 to 1000 do begin CheckFlushBuffers(I = 1000); {make sure last flushes} DoYourQuery; end; {for I} procedure CheckFlushBuffers(AForce: Boolean); begin Dec(AFlushCount); if AFlushCount <= 0 then begin Session.ForceBufferFlush := True; AFlushCount := AFlushInterval; end else if Session.ForceBufferFlush then begin Session.ForceBufferFlush := False; end; end; procedure ResetFlushBuffers(AInterval: Integer); begin AFlushCount := AInterval; AFlushInterval := AInterval; end; Hope this is what you needed, Sean Roy Lambert wrote: > timjones > > >> Rewriting a chunk of large 3rd party application framework is not very good ROI for our >> time. > > It is if it prevents errors and stops customers complaining > >> We use tools like DBISAM and application frameworks so our life gets easier and not >> more complex > > Without seeing your code obviously I can't comment on how much more complex it would get but I am surprised. My thoughts were based on the fact that you are creating the query. This means that you must be assigning the sql code to its sql property. so rather than > > - Create DBISAMQuery > - Execute SQL > - Destroy DBISAMQuery > - repeat 1000 times... > > You'd have > > create stringlist > add sql to stringlist > repeat 1000 times > assign sql to query > execute query > flushbuffers > destroy query > destroy stringlist > > > Roy Lambert |
Sat, Mar 22 2008 11:39 AM | Permanent Link |
Sean McCall | I'd add:
Session.ForceBufferFlush := False to the ResetFlushInterval so that it isn't left on and I'd also make sure it was set to false after completing the posting so it isn't left on for in the application. You may also be able to take advantage of the Session.KeepTablesOpen - While you want buffering: Session.ForceFlushBuffers := False; Session.KeepTablesOpen := True; When you want to flush: Session.ForceFlushBuffers := True; Session.KeepTablesOpen := False; which should close all the tables and force the flush on close. I would assume the buffers would flush with the close, but Tim would need to confirm this. Then, Session.ForceFlushBuffers := False; Session.KeepTablesOpen := True; would put it back to buffering. You could even put the flush sequence in the Application.OnIdle event handler and automatically flush the buffers when waiting for user input. Sean Roy Lambert wrote: > timjones > > >> Rewriting a chunk of large 3rd party application framework is not very good ROI for our >> time. > > It is if it prevents errors and stops customers complaining > >> We use tools like DBISAM and application frameworks so our life gets easier and not >> more complex > > Without seeing your code obviously I can't comment on how much more complex it would get but I am surprised. My thoughts were based on the fact that you are creating the query. This means that you must be assigning the sql code to its sql property. so rather than > > - Create DBISAMQuery > - Execute SQL > - Destroy DBISAMQuery > - repeat 1000 times... > > You'd have > > create stringlist > add sql to stringlist > repeat 1000 times > assign sql to query > execute query > flushbuffers > destroy query > destroy stringlist > > > Roy Lambert |
Sat, Mar 22 2008 5:28 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Robert,
<< Tim, what would happen if you do a database.starttransaction followed immediately by a database.commit(true)? >> Unfortunately, it's smart enough to know not to tell the OS to flush if nothing was written. -- Tim Young Elevate Software www.elevatesoft.com |
Sat, Mar 22 2008 5:30 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | << Rewriting a chunk of large 3rd party application framework is not very good ROI for our time. We use tools like DBISAM and application frameworks so our life gets easier and not more complex >> Yes, but doesn't all of this stem back to the issue with Vista again ? I find it a bit of a stretch that you're implying that DBISAM is somehow making your life difficult. If it's Vista, then MS is making your life difficult, not us. -- Tim Young Elevate Software www.elevatesoft.com |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Friday, March 29, 2024 at 03:30 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |