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

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]

> 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

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]

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

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

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

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

Roy

> I can do one of those - put in some SSDs

I did consider it - it certainly fulfilled one of the criteria

John

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