Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General Discussion » View Thread |
Messages 1 to 5 of 5 total |
new (to) threads |
Sun, Jul 1 2007 8:40 PM | Permanent Link |
"Monte Etherton" | Re: DBISAM v4.25.3 & D7
I have never implemented a TThread before, but I have what looks like a good opportunity to use one in place of the "brute force" approach in use now (set range & scan table in main thread while user waits for hourglass to disappear). I have not tried to code anything yet, because I don't know how...I'm just gathering prelim info. Thanks in advance for any advice on how to (and whether to) proceed! Here's a simplistic scenario: dbMain: Invoice data records dbNotes: Note records for each invoice (30K recordcount) dbMain & dbNotes are both displayed in a master/detail grid, which is the primary UI to this (multi-user) app. Every 10 minutes, a timer triggers a scan of dbNotes for "timed notes". These are note records that a user previously entered (usually as a future reminder). Once the date/time of the "timed note" is current, the app then sets a flag in the dbInvoice master record (so it is highlighted and the user is notified), while also attaching the note as a new detail record. Is this a good candidate for using a thread? If I create a TThread to execute the scan on the timer trigger, I assume I have to use different instances (created in the thread unit?) of each of the tables, but do I also need a different session & database? Once the thread terminates, is it then as simple as refreshing the UI instances of both tables to get the record changes to show? thanks again. Monte |
Mon, Jul 2 2007 3:00 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Monte
I'm slightly confused here. If you'e holding the date and time in a datetime field then a simple filter or range and checking .RecordCount is fast enough to find out if there are any records to be merged rather than a brute force scan. That aside. >Is this a good candidate for using a thread? As good as many >If I create a TThread to execute the scan on the timer trigger, I assume I >have to use different instances (created in the thread unit?) of each of the >tables, but do I also need a different session & database? However you start the thread you need full isolation. This means separate database, session and tables UNLESS you can guarantee that ONLY the thread will ever touch them. My approach would be to start the thread with the app, have it looping and set its terminate flag when the app is closed rather than to keep starting it with a timer. There have been loads of posts in the borland ngs borland.public.delphi.language.delphi.win32 about this - its worth going to have a look. >Once the thread terminates, is it then as simple as refreshing the UI >instances of both tables to get the record changes to show? Yes, but you'll have to send a message back to the main thread to do the refresh. You can't refresh them in the thread unless you use critical sections or synchronise and I'm not sure about that. Personally I PostMessage back to the main thread. Roy Lambert |
Tue, Jul 3 2007 12:27 AM | Permanent Link |
"Monte Etherton" | Thanks, Roy.
I do use a range, and have tried to make sure the routine is only fired when the app is idle...but it still takes control away from the user for a couple of seconds, and I thought using a thread would make it pretty much invisible to the user. So in your suggestion, the thread is continually running along side the main app? I was thinking that I could just create it when needed and then let it go. I'll do some more research on the ng's you mentioned. Thanks again...perhaps I'll learn this is overkill for what I will gain. -Monte "Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message news:9D41A22F-C711-4643-8002-A2A8FD1F68C7@news.elevatesoft.com... > Monte > > > I'm slightly confused here. If you'e holding the date and time in a > datetime field then a simple filter or range and checking .RecordCount is > fast enough to find out if there are any records to be merged rather than > a brute force scan. > > That aside. > >>Is this a good candidate for using a thread? > > As good as many > >>If I create a TThread to execute the scan on the timer trigger, I assume I >>have to use different instances (created in the thread unit?) of each of >>the >>tables, but do I also need a different session & database? > > However you start the thread you need full isolation. This means separate > database, session and tables UNLESS you can guarantee that ONLY the thread > will ever touch them. > > My approach would be to start the thread with the app, have it looping and > set its terminate flag when the app is closed rather than to keep starting > it with a timer. > > There have been loads of posts in the borland ngs > borland.public.delphi.language.delphi.win32 about this - its worth going > to have a look. > >>Once the thread terminates, is it then as simple as refreshing the UI >>instances of both tables to get the record changes to show? > > Yes, but you'll have to send a message back to the main thread to do the > refresh. You can't refresh them in the thread unless you use critical > sections or synchronise and I'm not sure about that. Personally I > PostMessage back to the main thread. > > Roy Lambert > |
Tue, Jul 3 2007 2:31 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Monte
>So in your suggestion, the thread is continually running along side the main >app? I was thinking that I could just create it when needed and then let it >go. I'll do some more research on the ng's you mentioned. You can, and in one app that's exactly what I do, but in that case the thread is triggered irregularly. You want one that runs regularly so its better to create it once and cycle it. Roy Lambert |
Tue, Jul 3 2007 3:31 AM | Permanent Link |
"Frans van Daalen" | "Monte Etherton" <monte[at-sign]automatedconceptsca[dot-char]com> wrote in message news:E1186412-830F-42B0-B455-2048C6A4887A@news.elevatesoft.com... > Thanks, Roy. > > I do use a range, and have tried to make sure the routine is only fired > when the app is idle...but it still takes control away from the user for a > couple of seconds, and I thought using a thread would make it pretty much > invisible to the user. If your thread take control away then some items used in the thread are not created in the .execute event of the thread and therefor running in the context of the main thread OR you are using synchronize in which case you need to get rid of that one using some other way. > > So in your suggestion, the thread is continually running along side the > main app? I was thinking that I could just create it when needed and then > let it go. I'll do some more research on the ng's you mentioned. creating and killing a thread is perfomance unwise hence his suggestion to create it once and let it run. You can lose the timer by using loop in the thread using a waitfor event > > Thanks again...perhaps I'll learn this is overkill for what I will gain. > |
This web page was last updated on Thursday, March 28, 2024 at 06:05 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |