LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Database toolkit memory leaks

Solved!
Go to solution

I have memory leaks in my Labview application connecting and inserting data into a MSSQL server using Labview Database Toolkit.

Versions: Labview 7.1, Toolkit 1.0.1.

 

I have searched the forums and searhed everywhere else...I see there are some issues. (For example List tables vi). Removing the list tables vi helped a lot. But I can still see that I'm loosing memory here and there, now and then.

 

My question is: Is there any general guidlines to prevent all memory leaks mentioned? 

Or possibly, will it all go away if I upgrade the versions. (As I understand I have too update Labview to be able to update the Toolkit?)

 

Best Regards

/Jesper

 

0 Kudos
Message 1 of 8
(3,315 Views)

Have you seen this Developer Zone document?

 

LabVIEW Database Connectivity Toolset 1.0.1 Known Issues

 

 

Functions, VIs, and Express VIs - ID 2F7E2352    

Memory Leak in the Database Toolset in DB Tools Open Schema VI

 

The DB Tools Open Schema VI leaks memory which if called continuously eventually causes a LabVIEW crash. This is a sub VI of the DB Tools Insert Data VI.

Workaround—At the highest level, if you are continuously updating values in a table, make sure the table already exists and leave the Create Table input to the DB Tools Insert Data VI set to FALSE.

 

Other than this, the most important thing is to close all references...


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

0 Kudos
Message 2 of 8
(3,304 Views)

Yes, I have seen it. The only thing I think applies to my case is the DB Tools Open Schema issue.

That vi is completely removed from my application. But I still see some leaks. (A lot less though! Maybe it is too little to worry about, but it is always hard to tell when you have a customer application running 24 h a day for months and months.)

 

I also have a 100 times larger labview application running on the same PC that does NOT have any leaks at all, thats why I am pretty sure it has something to do with the DB toolkit. It could of course also be something with the ODBC stuff....

 

About closing references.

1. I open a connection reference with Open Connection 

2. Then I use Execute Query, always followed by Free Object to work on the database.

3. On connection errors, I first use Close Connection and then start over from top.

 

Am I missing something with the references in the above example? Is Free Object the correct vi to use for closing the recordset reference after a Execute Query?

 

Regards

/Jesper

 

 

0 Kudos
Message 3 of 8
(3,297 Views)
Solution
Accepted by topic author zmilet

There is a small amount of memory allocated everytime you do an "open". If you are opening repetedly that could explaing a small slow leak. THe work-around is to open once and re-use the ref. Only clos it when you run into an error or are done.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 4 of 8
(3,286 Views)

Ok. Sounds that I have done what I can. But now I feel a little bit more safe.

 

Thank you for your support!

 

Regards

/Jesper

 

0 Kudos
Message 5 of 8
(3,265 Views)

In 2023, with LabVIEW 2018 I am running in to same issue with SQL tool kit.

Slow memory leak with SQL.

0 Kudos
Message 6 of 8
(696 Views)

This thread is about 14 years old and is marked as solved.  You would likely be best served opening a new thread.

 

Also, if you could actually post the code that generates the memory leak, that's basically a requirement for getting help.  Without that, it's nearly impossible to see the problem and suggest a solution.

0 Kudos
Message 7 of 8
(690 Views)

@_TestMan_ wrote:

In 2023, with LabVIEW 2018 I am running in to same issue with SQL tool kit.

Slow memory leak with SQL.


did you implement the solution in this thread?

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 8 of 8
(623 Views)