Aborting/stopping a loop while it is busy processing and unable to interrupt to check for a stop bool?

[DoctorAutomatic]

I'm working on a module that will be used to talk to an Oracle database (though I have had this question how it pertains to other situations also.

The database is a repository of millions of experimental data points. Thankfully, there is never a need to query the whole database, basically queries are limited to be within "projects" that consist of only 100K-3M data points. Queries can still take quite a long time if a user doesn't further constrain their queries. I can't hardcode limits to queries other than keeping them within a single project dataset, as there are times when someone wants all the data from a project. That said, often times a query may be taking a long time and I/users would like to stop the query either to rethink what they're querying or make other changes. I can NOT kill the db session through a second call to the DB as admin access will be prohibited.

Is there no way to kill a loop, or a process within the loop (whether that be a db query vi or some processing intensive data operation primitive)? I feel like I will have to resort to implementing a way to abort the vi via vi server. I don't know of a way to interrupt a db query in order to check for a stop bool. I also have some feeling like maybe there is something I can do with a timed loop, but I don't have much experience with timed loops so I'm really just guessing.

Is there just no way to gracefully (or ungracefully, if need be) tell a loop to stop whatever it's doing, mid iteration/mid node (when unable to check for a stop bool as one would normally design for), outside of aborting the whole VI via a vi server call to abort?

Hope I've properly conveyed what I am asking.

[cbutcher]

Without forcefully aborting the VI, you can't stop a loop mid-iteration.

If the database query has no mechanism to interrupt it (and it isn't programmed in a way that you can modify to add such a method) then you're left with aborting the VI.

You could consider using something like VI Server to call a subVI that only performs the query, and then aborting that, if needed.

Sometimes, long loop iterations can be split into multiple shorter iterations with a kind of "do this, then repeat doing this over and over until all of it is done" system that allows interruptions mid-task (but still not mid-iteration).

[Alexander_Sobolev]

From your question it seems you want to abort the loop (iterating too many times), but from description I understand you want to abort the query to the database (single operation within the loop). 

Can you split query into multiple if it will take too long?

Does database allow parallel commands to the same session (check status, abort query, etc) that you can send from parallel LabVIEW loop? Or you can try to close session from parallel loop, will it abort the query?

What happens with database if you spoil session (abort VI and do not close it properly)? Will it still be executing long query? If you call query VI dynamically, you can abort it without affecting main VI, but will session be still valid?

[Mark_Yedinak]

You might consider spawning a separate task to perform your query so that your UI is still response. Your UI would make a request to perform the query (this can be done using actors, spawning a VI dynamically, are creating a parallel task that handles DB communications and communicating with that task). Your UI would then go on its merry way and wait for a response. You could set a timer to indicate that the data was never received. If you want to abort the query you could send a message to your parallel task and it could destroy the reference to the DB interface. Are you using the DB toolkit? This would cause the query to error out and abort. We use direct TCP calls to communicate with a MySQL DB so in our case we could simply close the TCP reference. The VI that is waiting on the TCP read would fail because the reference became invalid and the query would be aborted. The DB would also see that the connection was closed and it should cleanup.

The benefit of separating the processing from the UI is that your UI will still be responsive to the user and capable of doing other things while the query is processing.