Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 11 total |
Flushbuffers |
Fri, Nov 18 2011 10:16 AM | Permanent Link |
John Hay | I have an application which handles input/output from about 20 dumb terminals. The app adds/edits records based on user
input. Each device has its own session/database and for safety I call flushbuffers on each table after they have completed their input (usually about 6 appends and a couple of edits). Unfortunately this is causing the app to go quite slow. If I add a process running on a timer which called flushbuffers for all tables (there are only 5 affected) in a different session does this flush the data for all the other session's tables? I have looked on tinternet for an answer but ended up more confused than I started! John |
Fri, Nov 18 2011 11:08 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | John
>I have an application which handles input/output from about 20 dumb terminals. The app adds/edits records based on user >input. How do you get dumb terminals running an app with DBISAM involved? >Each device has its own session/database and for safety I call flushbuffers on each table after they have completed >their input (usually about 6 appends and a couple of edits). > >Unfortunately this is causing the app to go quite slow. If I add a process running on a timer which called flushbuffers >for all tables (there are only 5 affected) in a different session does this flush the data for all the other session's >tables? Good question, and I'm not sure looking at the DBISAM pdf help but I'd guess yes. However, if you're looking at that approach why not use the Application.OnIdle event? Roy Lambert [Team Elevate] |
Fri, Nov 18 2011 11:21 AM | Permanent Link |
John Hay | > How do you get dumb terminals running an app with DBISAM involved?
They are RS422 terminals, with a membrane keyboard and lcd screen. > Good question, and I'm not sure looking at the DBISAM pdf help but I'd guess yes. > I'd be very happy if this is the case > However, if you're looking at that approach why not use the Application.OnIdle event? > This might work. I presume this is raised when the message queue is empty. My concern is if it raised to frequently I would be back to slowing down the app by calling flushbuffers too frequently. John |
Fri, Nov 18 2011 1:06 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | John
>> How do you get dumb terminals running an app with DBISAM involved? > >They are RS422 terminals, with a membrane keyboard and lcd screen. OK so that's what they are, still don't understand how it works - are you just sending text messages back and forth? >> Good question, and I'm not sure looking at the DBISAM pdf help but I'd guess yes. >> > >I'd be very happy if this is the case > >> However, if you're looking at that approach why not use the Application.OnIdle event? >> > >This might work. I presume this is raised when the message queue is empty. My concern is if it raised to frequently I >would be back to slowing down the app by calling flushbuffers too frequently. OK hows about a flag DoFlushBuffers and a timer. In the timer set DoFlushBuffers and in the application.onidle event if its set flush the buffers and unset it. Roy Lambert [Team Elevate] |
Mon, Nov 21 2011 6:27 AM | Permanent Link |
John Hay | Roy
> OK so that's what they are, still don't understand how it works - are you just sending text messages back and forth? You got it. In many ways it's like writing an old DOS app. Respond to keystrokes and write text to a screen. > OK hows about a flag DoFlushBuffers and a timer. In the timer set DoFlushBuffers and in the application.onidle event if its set flush the buffers and unset it. That makes sense, as long as the flushbuufers flushes changes/appends made in other sessions. John |
Mon, Nov 21 2011 8:11 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | John
Wonderful, I remember the days of IO mapped terminals well. From your posts so far I'm guessing that the reason for this is to prevent data loss, or it could be so that data is available to other users. Which? If the former, and since you've obviously had to write some sort of custom server why not just write a log file. Opening, appending, and closing that using Delphi's file management functions would (I think) cause it to be written to disk. Roy Lambert |
Mon, Nov 21 2011 8:32 AM | Permanent Link |
John Hay | Roy
> Wonderful, I remember the days of IO mapped terminals well. All good fun (not!) > From your posts so far I'm guessing that the reason for this is to prevent data loss, or it could be so that data is available to other users. Which? It is to prevent data loss. Flushbuffers doesn't affect data visibility. > If the former, and since you've obviously had to write some sort of custom server why not just write a log file. Opening, appending, and closing that using Delphi's file management functions would (I think) cause it to be written to disk. The dumb terminals are a very old version of the system and I am looking for the quickest, cheapest way of speeding it up (ie minimum rewriting/testing). John |
Mon, Nov 21 2011 9:06 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | John
>The dumb terminals are a very old version of the system and I am looking for the quickest, cheapest way of speeding it >up (ie minimum rewriting/testing). I can do one of those - put in some SSDs Roy Lambert |
Mon, Nov 21 2011 10:46 AM | Permanent Link |
John Hay | Roy
> I can do one of those - put in some SSDs I did consider it - it certainly fulfilled one of the criteria John |
Mon, Nov 21 2011 11:52 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | John
>> I can do one of those - put in some SSDs > >I did consider it - it certainly fulfilled one of the criteria Just thinking laterally here - with the cost of hard drives escalating maybe you can sell the current one for enough to buy an SSD Roy Lambert |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |