LPurvis
AWF VIP
- Local time
- Today, 14:34
- Joined
- Jun 16, 2008
- Messages
- 1,269
>> This one line of code has pretty significant implications to me, like overnight it'll change how I do data access for class modules.
I was just thinking that I might as well mention, even though it's not likely to play a part in your decision or implemenation, that the connection used by a disconnected recordset can't always be destroyed. (Note that it is the connection itself - not the connection object, that's a gonner if you so decide).
Obviously, under normal circumstances, its a convenient tool at your disposal - open a connection, fetch data, disconnect, close the connection and continue to read the data for local access and manipulation without affecting the source.
While your recordset data is disconnected by the above code, regardless of other considerations (so long as it obeys the requirements for disconnecting a recordset of course which is, primarily, it being client side), the connection of a Shaped Jet recordset will persist.
i.e. (assuming a shaped recordset was opened...)
Set rst.ActiveConnection = Nothing
cnn.Close
ends the connection of those objects - but the physical connection is persisted until the recordset is closed too.
(This is trivial to determine in Jet, no Trace required, you can just watch the LDB file creation/destruction.)
As mentioned, the connection object can be closed/destroyed. The recordset is indeed disconnected. It can only be the shaping provider that causes ADO to internally hold open a connection until the recordset closes.
If you never employ shaped recordsets to external Jet data sources then it won't be an issue - and even where it does apply, it's not likely to impact what you're doing. You would generally just assume that the connection has terminated when it hasn't.
I mention it only since, AFAIK, that is the single except to successful disconnection.
Cheers.
I was just thinking that I might as well mention, even though it's not likely to play a part in your decision or implemenation, that the connection used by a disconnected recordset can't always be destroyed. (Note that it is the connection itself - not the connection object, that's a gonner if you so decide).
Obviously, under normal circumstances, its a convenient tool at your disposal - open a connection, fetch data, disconnect, close the connection and continue to read the data for local access and manipulation without affecting the source.
While your recordset data is disconnected by the above code, regardless of other considerations (so long as it obeys the requirements for disconnecting a recordset of course which is, primarily, it being client side), the connection of a Shaped Jet recordset will persist.
i.e. (assuming a shaped recordset was opened...)
Set rst.ActiveConnection = Nothing
cnn.Close
ends the connection of those objects - but the physical connection is persisted until the recordset is closed too.
(This is trivial to determine in Jet, no Trace required, you can just watch the LDB file creation/destruction.)
As mentioned, the connection object can be closed/destroyed. The recordset is indeed disconnected. It can only be the shaping provider that causes ADO to internally hold open a connection until the recordset closes.
If you never employ shaped recordsets to external Jet data sources then it won't be an issue - and even where it does apply, it's not likely to impact what you're doing. You would generally just assume that the connection has terminated when it hasn't.
I mention it only since, AFAIK, that is the single except to successful disconnection.
Cheers.