Database List Tables VI leaking memory

[stockley31]

Hi All,

I have a problem with a memory leak and the database tools.

I have created a tool that uploads data from a datasocket to a database.  As part of this tool, I am running a check to confirm that the table exists in the database, and if it doesn't, I create the table.

After searching long and hard for a memory leak in my code, I have found that there seems to be a memory leak in the 'DB Tools List Tables.vi' code somewhere.  Has anybody else come across this?  I seem to be gaining 4K every ~ 2 seconds when running a testing VI that opens a database connection, then loops every 500ms to run the List Tables function.

I have tried the changes suggested in other posts (such as creating a constant array attached to the actual CIN node), I have also attempted closing the ADO reference (which crashed my tester!).

Is there any update expected for the toolkit?  There was some suggestion of an update in another post (2005), but I'm not sure if there has been an update since then.  Also, how come the schema constant in DB Tools List Tables doesn't match the data type for the control in DB Tools Open Schema.vi?  There seems to be a misalignment of the enum - adSchemaTables = 20 in the constant & adSchemaStatistics = 20 in the control.

Any help with this would be greatly appreciated.

Regards,
Slade

[tst]

My guess is that the toolkit will not be upgraded soon.

It's a good question why the listing is different. The constant is a ring which can (and does) have negative values as well. Perhaps the inconsistency is coerced somewhere.

I don't think I ever used the List Tables VI in a production system, so I didn't run into any problems with it. You might wish to check out this thread. A different function, but maybe the same problem?

[stockley31]

Thanks,

I've worked around it for now, I've implemented a query that checks the MySQL information schema for the details.  Unfortunately, this makes it DB specific to start with, but I'll revise that later.

I hope NI revisit this when (if) they ever have another look at the DB tools!  I would think it was fairly important in any generic logging to a DB to check if the table exists via that function...

Regards,
Slade

[Nadim R]

Hi Slade,

I'm glad you were able to find a workaround.  Would it be possible for you to replicate your issue on a smaller scale and post that snippet of your code to this discussion forum.  That way, I will be able to test your VI and report any memory leaks to R&D for further investigation.

Good luck in your future endeavours,


Regards,

Nadim
Applications Engineering
National Instruments

[stockley31]

Hi,

Sorry it has taken so long to return to this.  Couldn't upload the file at work (damn content blockers), and got dragged off onto another project.

Please find the file attached.

cheers
Slade

[Spex]

Hi Slade,

Thanks for taking the time to create this example.  This was reported to R&D (# 2F7E2352) for further investigation.  I am not a SQL expert... if you have a chance, can you post the SQL query and/or the snippet of code you used to work around the issue so anyone else that runs into this issue may use your workaround until the memory leak is resolved?

Cheers,

[stockley31]

Hi Spex,

The SQL query I used was
    SELECT table_name
    FROM `Information_Schema`.`Tables`
    WHERE TABLE_SCHEMA='%s'

This was used for a MySQL database, although I believe the information_schema database should be present in all database's now.

Regards,
Slade

[Spex]

Thanks Slade!

I was also able to find a workaround using the SQL query:

SHOW TABLES;

That was also for a MySQL Database, and I don't have enough database experience to comment on how universal that implementation is ;).

Nevertheless, my implementation is attached below.

Cheers,