In the email subsystem for my app I have written a class which contains procedures to download and check headers (FetchHeaders) and if wanted store in a table (emInbound) which is later processed by another procedure (ProcessBodies). The intention is that I'll create a couple of threads, instantiate a copy of the class in each one (say grabber to fetch and sorter to process the downloaded stuff) and leave them merrily playing. For the poor souls still on dialup it means the shortest connection to the internet and by checking headers first reduces traffic as well.

If I instantiate and call grabber.FetchHeaders followed by sorter.ProcessBodies sorter.ProcessBodies says there are 0 records in emInbound, its not until the app is closed, reopened and run again that sorter.ProcessBodies realises there are records in emInbound.

I call grabber.FetchHeaders followed by grabber.ProcessBodies it sees 54 records which is right.

It explains why I was having trouble when I had things threaded but I have no idea what's going on.

The class creates its own session, database, tables and queries so it has full isolation for when it is threaded. My first thought was I'd screwed up something in the threading but the behaviour is the same in the foreground.

Can anyone cast light into my darkness?

Roy Lambert

Roy,

<< I call grabber.FetchHeaders followed by grabber.ProcessBodies it sees 54
records which is right. >>

What's the difference between grabber.ProcessBodies and sorter.ProcessBodies
?

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

Never mind, I get it now.  Are you opening up the tables, queries for the
first time when you call the sorter.ProcessBodies method ?  Or are they
already open because the thread is in a wait state waiting for something to
do ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Never mind, I get it now. Are you opening up the tables, queries for the
>first time when you call the sorter.ProcessBodies method ? Or are they
>already open because the thread is in a wait state waiting for something to
>do ?

I'm not sure what was going on when I had it threaded but in the foreground both grabber and sorter as part of their create routine create sessions, tables etc and open them up (actually through a sub class but that shouldn't matter). What I did was

In a timer event check if not already initialised and if not create grabber and sorter so this is the point at which tables will be opened. In outline the loop goes

if not already
initialise
    set up grabber
    set up sorter

call grabber.fetchheaders
if there are records in emInbound call sorter.processbodies

So the answer is they're already open. I guessed where you're coming from and I've added a refresh and its working. The start of processing the bodies now looks like

iemInbound.Refresh;
 iemInbound.First;
 while not iemInbound.Eof do begin

I thought the .First would cause a refresh which is why I never had one in there.

Still working now.

Roy Lambert

Roy,

<< I thought the .First would cause a refresh which is why I never had one
in there. >>

It may or may not.  The only way to know for sure that there is a refresh is
through the Refresh method call (or REFRESH SQL/PSM statement).

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>It may or may not.

I do love these really positive actions

Roy Lambert

Roy,

<< I do love these really positive actions >>

Okay, the actual answer is that it depends upon:

The active filter, range, and/or index.
The current row in the table.
How many rows are in the table.
The row size.
How big the buffer sizes are for the table.

and probably one or two other things that I forgot.

--
Tim Young
Elevate Software
www.elevatesoft.com