Database interface

Bayley, Alistair
Thu, 21 Aug 2003 10:16:05 +0100

> From: Tim Docker []
>  > It also has the benefit that the function you pass to doquery can
> make
>  > other calls to doquery, without mucking up the 'current row' state.
>  > There would be one current row per Cursor, not one per Process.
> Is it normal or common to support multiple simultaneous queries on
> a single DB connection?

Depends on what you mean by "multiple simultaneous queries". A single query
is usually synchronous w.r.t. returning a cursor i.e. you issue the query
and get back a cursor in an atomic operation, and then you can do other
things while you fetch rows from the cursor.

If you need to have two SQL statements running at the same time (two big
inserts or updates, say) then you usually need two sessions. It probably
depends on the API, but some (Oracle, I believe) will allow you to open
multiple sessions with the same connection.

In a single session you could open a number of cursors (in any order),
interleave fetches (in any order), and then close the cursors (in any

So you could have:
 - a number of Connections (perhaps to different servers/databases), where
 - each Connection has one or more Sessions, and
 - each Session has zero or more Cursors (and one current Transaction).

My session model and terminology are probably quite Oracle specific, but I
hope it's reasonably clear.

The information in this email and in any attachments is 
confidential and intended solely for the attention and use 
of the named addressee(s). This information may be 
subject to legal professional or other privilege or may 
otherwise be protected by work product immunity or other 
legal rules.  It must not be disclosed to any person without 
our authority.

If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you 
are not authorised to and must not disclose, copy, 
distribute, or retain this message or any part of it.