Database memory leak

[SteveChandler]

Have you run the Desktop Execution Trace Toolkit? It is an addon and well worth the money. Like other NI software there is an evaluation period.

[euTeam]

I have similar database problem see attachment: memory grow and decrease only when I close labview.exe.

Thanks all.

Euteam

[MikeBl]

I only have LabView 9 so I cannot open your files.

I have currently worked round the problem by finding a way to monitor the memory usage from within the LabView program, and when it gets too high I restart the program. This is done by executing another program from the LabView program and terminating the current program. This other program then executes the real program again, and terminates itself.

Hope this helps.

The original problem has not been solved.

[craige]

I think euTeam did a very nice job of demonstrating the issue. (Very clean VI, good use of Functional Globals). I stumbled across this thread because I too am having problems with memory leaks when using a mySQL server, Database Connectivity Toolkit 2010, and LabVIEW 2010 SP1. I've run euTeam's example and can confirm that memory is leaking on my Windows XP SP3 machine as well. Even after closing the VI the LabVIEW splash screen still holds onto more than 1GB of memory (yikes!)

So far solutions on this thread have been pretty weak. (Yes, I ran the Fetching Example that ships with LabVIEW, not really a good comparison to querying for continuously updated data.) 

I'm starting to dig around under the hood and look at the ADO approach that NI uses. Perhaps comparing this to an example might help. If I can find anything useful  I'll let the group know.   

Regards,

Craig

[Matthew_Kelton]

I am also seeing drastic memory usage issues with the DB Connectivity toolkit.  I have some code with needs to load an entire database into memroy to fix some relationship problems.

In LabVIEW 8.6, this will run and take about 600MB of memory.  In LabVIEW 2011, it is over 1.5GB (often LabVIEW runs out of memeory here).  I went back to LV 2009 and saw the same behavior.  After doing some checks, the DB Connectivity toolkit seems to be the culprit.  I can see between LV8.6 and LV2009, some changes were made to the toolkit that I imagine are the cause of the problem.

[Matthew_Kelton]

I have found a major change in how variants are handled starting in LV2009 and is still present in LV2010 and 2011.  They consume a lot more memory and LV doesn't seem to be recovering the memory, either.

See this thread:

http://forums.ni.com/t5/LabVIEW/LabVIEW-memory-management-changes-in-2009-2011/m-p/1748886/highlight...

[craige]

I've been doing a lot more testing. I think the basic problem lies in the GetRows method of the ADO API not the Convert Variant to Data function (although this contributes to the problem).

I've structured the attached files off of the "Using Command Object" example as provided by microsoft. (I'm ignoring the Database Connectivity Toolkit altogether here)

http://msdn.microsoft.com/en-us/library/windows/desktop/ms675065(v=VS.85).aspx

When I return data using the GetRows method (myADOTest_Rows_NI.vi) my computer allocates memory under the LabVIEW memory space but never releases it. As long as the dataset returned is the same size then the memory allocation is never compounded. Its only when the query returns MORE rows that a new allocation is required. Regardless, the memory is never released. When adding the "Convert Variant to Data" function into the example the problem is greatly magnified.

Conversely, when  I return data using the Fields.Value property (myADOTest_Fields_NI.vi) my computer allocates memory but then deallocates it. I can run this VI as many times as I want and memory allocation actual behaves! Even when I introduce the Convert Variant to Data function memory is allocated and then deallocated as expected. Downside is that this takes much longer since it requires me to move between individual fields instead of by rows.

Let me know if this rings true with anyone else on this thread. I desperately need a solution to the GetRows method memory leak.

Thanks,

Craig

[Ad_Dekkers]

Any solutions available yet ?? !!!

[craige]

I called NI this morning and spoke with an application engineer. Unfortunately CAR# 321353 is still open and no resolution has been found.

For now the only solution I've found has been to build the code in LabVIEW 8.6.1. Extremely annoying for numerous reasons since my customer requires LabVIEW 2010sp1 in order to run other LabVIEW features. This means that I have to purchase and maintain two development environments on my development machine, must deploy two run-time engines on the target PC, and have to launch my 8.6.1 code as an exe from my LabVIEW 2010 using the ShellConsole VI. The project is now over budget.

[Ad_Dekkers]

I have the problem with lv 7.1 and lv 2011 sp1.

Special in a .exe.