Thanks guys, for all the prior info...but, getting some strange behavior now...

Not really sure what's causing this, but I had built some mini-apps to play
w/ the cn.Close method between recordset population calls. My test projects
worked fine, when I checked the sessions on Oracle...there was nothing there
for my userid while my app was up and running, all connections had been closed...and
I assume they were still in the connection pool on the client because I could
see a performance diff if I added a set cn = nothing. I had built a function
to open a recordset by passing a sql string and recordset to the function.
In the function I do a cn.open and a cn.close before/after the data is pulled.
I also set the rs.activeconnection = nothing before exiting the function.
All worked great, worked with the data locally, reconnected, worked as expected...not
a single connection showed up on the Oracle end until I reconnected the connection
and recordset to update the data to the database.

So...my test projects work fine but my production project which has quite
a few recordsets passed by reference into this function are not working now...not
sure why...in fact, this app shows MULTIPLE sessions in Oracle for the same
app and user...very STRANGE...

Anyway...just thought I'd post back w/ my results...going to have some series
debugging to do...there really isn't anything different w/ my production
project and test projects...so this may end up being quite a problem to solve.

Chris

Paul Clement <UseAdddressAtEndofMessage@swspectrum.com> wrote:
>On 7 Jun 2002 13:24:11 -0800, "Chris Hylton" <cchylton@hotmail.com> wrote:
>
>
> Michael, already considered that option...to disconnect when not in use...the
> pooling/resource sharing capabilities of OLEDB will keep a connection

available
> (at least for awhile) so a reconnect should be fairly fast...but, still

not
> an optimal solution...some apps are a quick in and out, some take awhile
> to pull data down or execute a proc...
>
>Once you release the connection through your app, it is returned to the

pool. If the
>connection is
>idle for one minute (OLEDB) it is destroyed.
>
>
> Paul, not sure I see what you mean...I might be confused though...if I

had
> a single connection object housed in some sort of an activex exe/document
> app...every app would send requests for data through that object...the

apps
> are obviously only hit one at a time by the user...
>
>Correct. If you are using a multi-use ActiveX EXE to share a connection,

then blocking
>will occur at
>the component level under concurrent access.
>
>
> So, let's say that the toolbar is opened, with buttons for 10 apps on

it...the
> toolbar spawns off my custom 'connect' object...then spawns off 2 apps

(#1
> and #2)...both in their own space (seperate EXEs)...no EXE would really

be
> sending a request through the connection object at the same time, but

I guess
> it's possible...for example, if app #1 sent a long running proc through

and
> then the user clicked on app #2 and tried to query data...then I guess

that
> might create the situation you are referring to (blocking)...where #2

can't
> get to the connection because #1 has it tied up.
>
> Is that what you are talking about ?
>
>Yes.
>
>
> Makes sense I guess...maybe I do want a seperate ADO connection per app...might
> have to explore the .Close method that Michael brought up...I had already
> tested this a few days ago and it works fine...just requires reconnecting
> w/ every call to a recordset or command object.
>
>Probably why it's just better to stick with the connection pooling provided

by the driver
>manager
>services. If you want to reduce the number of connections for each desktop,

just make
>certain each
>application closes a connection after it has been used.
>
>
>Paul ~~~ pclement@ameritech.net
>Microsoft MVP (Visual Basic)