LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unfreed database recordset references but closed connection references

When database connection references are closed do the associated  recordset references also get freed?

if not is there a potential issue if recordset references are not freed but the connection references are closed?

0 Kudos
Message 1 of 5
(2,088 Views)

That will probably depend on the library used...

0 Kudos
Message 2 of 5
(2,055 Views)

Database connectivity toolkit

0 Kudos
Message 3 of 5
(2,045 Views)

When using references with Database toolkit, I normally close all references, first recordset, then connection.

I found that not closing connection references caused various issues, expecially when doing a big number of continuous queries (e.g. 1 or more per second, not closing references someway creates memory leak and response slowing after some time).

I think that it is reasonable to think that if recordset are not closed, and opening recordset reference is called a large amount of times, this could lead to some problems with the time...

So it would be a good approach to close every recordset reference, too. 

Anyway, probably it would not be a problem if you rarely call an open without closing recordset reference ..

This in my opinion.

0 Kudos
Message 4 of 5
(2,040 Views)

@naiveinquirer wrote:

When database connection references are closed do the associated  recordset references also get freed?

if not is there a potential issue if recordset references are not freed but the connection references are closed?


The quick answer is: Absolutely not!

 

The Database Connectivity Toolkit access the ADO DAO interface which is ActiveX based. The lifetime of ActiveX objects is reference count based that means everytime you obtain a reference to an object the internal object reference count is increased by calling the AddRef() method of the ActiveX IUnknown interface. When you "free" and object, all that is done is calling the Relase() method of that interface and that decrements the internal reference count and only when that count reaches 0 is the object effectively deallocated.

 

You obtain a reference when you create an object but also every method that returns an object reference is obtaining a new reference to that object. LabVIEW wraps those object references into its own refnum for easier management but for the purpose of a user you can view the refnum as the same thing as the underlaying AciveX object reference.

 

Note that a recordset object often also maintains a reference to the connection as that is required for certain operations sometimes. That means not closing a recordset you obtained somehow or an object inside a recordset which always will retain a reference to the recordset, ultimately also keeps the connection object alive!

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 5
(2,034 Views)