Query slowing down main thread

[AntonioNI]

I have a SQL Query running in a asynchronous vi call. This Querry take about 700ms to execute, and its Vi procces the data in 2s (Query included). This asynchronous subvi, then Queues the results in to the main While loop in the main VI wich called it. My problem is that In the moment I call my subvi, the main VI loop takes this 700ms (as if the query time is solowing it down even tho it's on separated vi's).  Any clue on how to run querys withou solowing down my main aplication? 

PD: The subvi is low priority while the main is time critical.

[Rob_Calhoun]

If the asynchronous database call returns a value, then you are dataflow linked to it and the execution will wait until the call completes. You need to break up the reader and the user.

A common code pattern in LabView is a "producer-consumer" loop where one loop generates the data and one or more loops read it. Queues and Notifiers are used to manager sending messages between the threads. Use a Queue for 1..n writers and a single reader, Notifier for a single writer (although can be 1..n ) and 1..n readers. This is shown schematically below.

You can also use queues/notifiers to quit parallel processes in a timely manner, since Wait On Notification / Read Queue release immediately when the refnum becomes invalid. I call this "scuttling". We usually have a "Quit Notifier" that we use for bringing the whole app down. Various housekeeping tasks that need to run once a second or once a day (set using the timeout) and "wait on notification" that never comes, until the refnum becomes invalid and it's time to quit.

One special thing to note with SQL calls is that the database toolkit uses ActiveX (or at least it used to.) LabView can't schedule ActiveX processes in the same way it schedules LabView tasks. ActiveX tasks get a real (OS) thread and block that thread until completion. LabView it is possible to run out of OS threads in a given execution system if you make a lot of parallel, slow ActiveX calls. (This is not your problem, just something to be aware of.) There is no practical limit that I know of to the number of parallel "regular LabView" tasks.

[AntonioNI]

I think im doing it just fine, I call a subvi asynchronously with my slow query and then Queue the results in to the main queue of my main vi. Still seems thet the execution time of the Query is limiting. Can you run asynchronous querys on to SQL? Becouse the main vi keeps throwing querys, so maby it stop becous its has to wait for the long query to finish.

[AntonioNI]

I have seen that the DB Tools VI's that Im using have non reentrant execution. Could this be the problem? And how to fix it?

[Bob_Schor]

Please do not attach pictures -- attach VIs or Snippets (which "look like" pictures, but expand to actual LabVIEW code).  I can't see the relevant part of your VI, but if doing a query to SQL is slow, and you need to do multiple queries, and they need to be done sequentially (since it seems unlikely that you can have multiple SQL engines simultaneously retrieving data from the same database), that, it seems to me, sets the limit to the maximum speed of your entire process -- it cannot go any faster than the data can be produced.

I'm assuming you are getting the data from SQL.  If you are putting the data to SQL, you can, indeed, go faster, but only up to a limit.  Say it takes a second to write a record.  If you need to write 100 records, but can generate them all within 5 seconds, your Producer loop will finish in 5 seconds, and if you have sufficient space in your transfer Queue for the 100 records, the Consumer loop will finish 95 seconds later.  Don't try this with a 10,000 records (it will take a lot of memory, and almost 3 hours ...].

Bob Schor

[crossrulz]

---

@AntonioNI wrote:

I have seen that the DB Tools VI's that Im using have non reentrant execution. Could this be the problem? And how to fix it?

---

That would only be an issue if you were trying to call the same VI in multiple places at the same time.  I do not think you are doing this.

Even though you are calling your read VI dynamically (why?), it must complete before your loop can iterate.  As we have told you before, you need to make the database access in a parallel loop.