Open Database Connections

[mike_22]

I've ported some code over from LabVIEW7.1 to 8.6 which updates a table in a MYSQL database.  The problem is that the new code leaves a database connection open after execution (while the 7.1 code does not).  I would like to know if anyone has seen this behavior and if they know a fix, and if not, how would they go about debugging this problem.

I am using the MYSQL ODBC connector, version 5.1.

Some observations:

1. This vi is part of a TestStand 4.2 sequence, and the sequence writes results at the end of testing using TestStand's built in functionality to do this.  What's notable is that unlike the vi, the database connection used to write the results is closed properly.

2. I've used the "trace" tool in windows ODBC panel but the information is overwhelming large, cryptic and doesn't  contain recognizable strings.  To reduce the size of the file I tried to start and stop it so that it was tracing only during the execution of the vi.

This didn't work - the tool did not record any information.

3. Stepping through the vi...

     a. The database connection problem does not appear.

     b. The error cluster is always empty indicating no errors have ocurred.

4. No errors happen during normal execution.

5. I've added delays of 5 seconds between some of the database vi calls and still the database connection is left open.

The vi that's causing the problem is attached.

Thanks in advance.

[Yamaeda]

You have a clean error in the middle, but i dont see how that should cause this. I reacted a little to the Select query using double quotes instead of single ones, NID="***"; instead of NID='***';
Might that be a reason?

Unpacking that sequence made it easier to read, i might add. 😉

/Y

[David_L]

I'm with Yamaeda on unpacking the sequence here.  You are doing a good job of using the error terminals, having the stacked sequence structure just makes it much more confusing to read.  You NEVER need a stacked sequence structure, and not even a flat sequence structure when you have good error handling like you do.

[mike_22]

I've replace the double quotes with single quotes and unfortunately the vi to close the database connection isn't working.

Does anyone have any other ideas?  Is there a low level or debug version of the database connectivity vi's that I can use?  I need some debug capability here.

[Yamaeda]

You should be able to open the Database Connectivity VI's and place breakpoints and Highlight Execution in them (i've done), which really help to solve the issue. I just recently discovered that the Insert Data didn't handle column names with spaces since there's no true standard to such naming. SQL Server uses [column name] e.g. so to pass such issue you'll have to build your query yourself and use 'Execute Query' or simplify names.

/Y

[tbob]

My advice is to get rid of the sequence structure and either string everything along left to right, or preferably use a state machine.  Turn on highlighting and look for an error condition on the error wires.  Maybe put a probe on the DB reference wire and compare what you see to the value after the DB open function.  An improper reference or an error could cause the DB to not close.

[mike_22]

I've already tried these suggestions.  See observation #3 above.  The problem doesn't happen when I step through the code.

[tbob]

No problem when stepping through the code and having a problem when running at full speed suggests a timing problem.  Try putting delays at various places.

[mike_22]

Regarding the delays, see observation #5 above.  Might want to check those observations again.

[mike_22]

Am I missing something obvious?  Waiting for me to see it?