At 05:21 PM 30/09/2007, you wrote:

> > >After one thread fetches data from the select, can't the other
> > >thread use it?
> >
> > No.
>
>Thanks again Helen.
>
> I think I'm not being clear. Or I'm confused. "it" means
>the data from the select, not the connection.

You're confused apparently because you think "the data from the
select" has nothing to do with the connection.

Let's look at this from the bottom up. "Data from the select" is the
set of records sent to the buffer in response to a SELECT statement.
The SELECT statement is executed in the context of a transaction by
way of a connection. The bits and bobs that the server maintains
pertaining to that statement belong to the transaction that requested
them. The transaction, in turn, belongs to the connection through
which it is conversing with the server.

The actual data and metadata attributes that the client program
fetches from the buffer, in order to do something with it, such as
display it in a graphical tree, is a snapshot of the state of the
database at that time, through that connection, via that transaction
and that statement.

>The other thread can use the data can't it?

NO. The other thread will have to open its own connection, start a
transaction over that connection and request its own set. All for its own use.

>After what you and Adam have told me, I wouldn't try to have threads
>of one process share a connection.

That's right. Because each thread must have its own connection and
its own context. It can't share that context with any other thread,

> My approach now is.
>
> Main thread of parent process:
>
> Draw some dialogs
>
> Launch data extraction thread
>
> Wait for message from data extraction thread that info
> needed for login to application is available in regular
> memory
>
> Run logins using user records retrieved by thread
>
> Create new processes for any task the user chooses to
> perform. These processes will traverse a binary tree
> in shared memory. They will use the contact's primary
> key, found in a node of the tree, to extract columns
> from the contact table.
>
> The main thread never connects to the database. If it
> ever needs to in the future, it will be after data
> extraction thread is finished.
>
> Data extraction thread (For parent process):
>
> Connect to Firebird
>
> Extract information needed for user login to application
> in regular memory
>
> Inform main thread login information is present
>
> Load small number of columns from each row of contact
> table into binary tree in shared memory
>
> Inform any processes waiting for the contact information
> of the progress of the load.
>
> Disconnect from the database.
>
> end
>
> Only one connection will be made by a process.
>
> Does this sound like it will work?
>
> Sorry about being so dense. But that's just the way I am.

If this is an accurate description of what you plan to do, then what
you're planning is not a database application, it's a report. Sure,
you can retrieve some data from a database, convert it into some form
that your application can understand and then copy that converted
data somewhere: to a file, to a memory structure, to a printer, to a
graphical display, to a son et lumiere show.... but it's a
report. It's a snapshot of what was visible at one moment in time
when something in your program peered through one connection via one
transaction. It's dead data (as all reports are).

./heLen