Database Connection Reference in While Loop

[kacperek]

@aputman trust me. My application is build on Actor Framework. DB reference is in private cluster of Database Helper Actor Class, so i close connection only when actor stops working. This is not simple "datafalow" VI.

Regards,

Kacper

[aputman]

Try recreating the input terminals on the while loop.  Sometimes it happens that i create two by accident.

[Wart]

It'd be useful if you posted code we could run.  I couldn't replicate the issue using the SQL Server Native Client on my local machine.  Your original code could benefit from an error wire, though it does look like you've used one in some of your testing.

Can you give us more information on the structure of your code?  Is the database connection opened as part of the actor that is using it, or do you open one connection that is shared across actors?

[kacperek]

It works fine in simple VI. It's hard to post my entire code. That is the part od Controller actor before Launch Actor. But i have separate object (My Own Database Class) where i intialize and check connection.

Now i'm on the scent of this problem. If a wait in while loop is short - for example 10ms, code runs fine 25-30 times, and throws error. So it must be asynchronous issue. The worse thing is, when i put main error wire through this loop using shift registers, so it should "stop" within this loop unless stop condiction, this error behaviour doesn't change - it runs only a dozen times and stop loop via error true condistion. I think, in this case there is no other parallel code running, but problem occurs.

I think this could be not LabView, but ODBC driver issue.

[tst · Accepted solution]

LV has an automatic cleanup mechanism for references - when a hierarchy that a reference was created in goes idle, the reference is automatically destoryed. A hierarchy, in this context, is determined by the top level VI (that's the VI where the run arrow was pressed or which was run using the Run VI method or the ACBR node, which applies in the case of an actor), so once that VI goes idle, and reference created by VIs it called is destoryed. My guess is that you open the connection before you launch the actor, pass it in and then the calling hierarchy goes idle, causing the reference to be destroyed. There are other options too, but without code, it's hard to tell.

In general, it's important, particularly when working with the AF, to assign responsibility for resources to the different elements in your code. That should include managing the connection to the DB. In any case, it's also important to handle errors - DB connection errors are a perfectly legitimate scenario, and your code should handle them (for instance, by closing the connection and trying again at least a few times).

[kacperek]

@tst i think that's correct answer. I initialize connection in Launcher VI, then run Controlle actor, pass refnum, and close Launcher. Funny thing is, that connection reference is valid for a short period of time after Launcher VI stops, so one can qucikly run query to database at the beginning of Controller Actor Core.

Thanks everyone,

Kacper

[aputman]

---

@kacperek wrote:

@tst i think that's correct answer. I initialize connection in Launcher VI, then run Controlle actor, pass refnum, and close Launcher. Funny thing is, that connection reference is valid for a short period of time after Launcher VI stops, so one can qucikly run query to database at the beginning of Controller Actor Core.

Thanks everyone,

Kacper

---

....And that it is always valid on the first loop iteration but not the second.  That is such a finite window that the odds seem impossible. 

[kacperek]

@aputman check my previous posts, it's valid for first iteration only if i wait 1000ms in loop. When i wait 10ms, then connection refnum is valid for 20-30 iterations and it's not constant value.

[kacperek]

If you want to reproduce this issue, then run AF Template from >=LV2012. Initialize connection in Splash Screen.vi and pass reference to main actor private cluster. Then in it's Actor Core try to use conection. Try at beginning of dataflow, and after some time.