reentrant Database execute

[Nils_Gokemeijer]

It seems to me that you can have multiple connections to a database, but a lot of the Database toolkit VIs are not reentrant.

I have two connections, and by making a number of the database toolkit vis reentrant, I think I can significantly improve performance.

Any considerations on doing this for the next toolkit release?

Thanks.

[rolfk]

---

Nils Gokemeijer wrote:

It seems to me that you can have multiple connections to a database, but a lot of the Database toolkit VIs are not reentrant.

I have two connections, and by making a number of the database toolkit vis reentrant, I think I can significantly improve performance.

Any considerations on doing this for the next toolkit release?

Thanks.

---

That should be generally not necessary for most of the VIs since they do not execute code that takes long to run.

There is an issue with making all possible VIs reentrant by default. This requires a lot more resources such a memory and that is not a good idea if it is not required in an application. Also most database applications are kind of sequential anyhow so there would be little gain with a lot of pain for many applications.

I would tend to make VIs not reentrant by default expect those that are clearly meant to wait for some time on something and there is a high probability that they can be executing multiple times in parallel in a typical application. The database Vis don't strike me as being in that category very much for the majority of users, most are not even in the first class.

Rolf Kalbermatter

Message Edited by rolfk on 04-20-2009 11:07 AM

[Nils_Gokemeijer]

I haven not reviewed in in depth, but there are at least three that would really benefit from being reentrant:

 Conn Execute.vi    This vi executes an SQL query and waits for the databaset to return a recordset,

 Cmd Execute.vi     This vi executes an SQL command by reference and waits for the database to return a recordset,

 DBTools Select All Data.  This has Conn Execute.vi in it, if Conn Execute is reentrant, this one should be too, otherwise you still get stuck.

Just my 2 cents.

[Dennis_Knutson]

Whether or not the subVIs are reentrant or not, you will still have to wait for the recordset. Are you running multiple queries in parallel?

[Nils_Gokemeijer]

Exactly, I am running two separate connections.

Let me give you an example: I have a table of values on my front panel. Then I allow the user to change certain values in the table.

Each time the user changes a value one connection updates the value in the database.

At the same time, I have a second connection that refreshes the table from the database in the background. By making the vis reentrant I was able to do this seamless to the end user.

Now that I just upgraded to 8.6, I found out how much this affects my program, because the new toolkit is not reentrant, and I remodified the vis.

Another example is a fairly long saved procedure in the database that verifies the database integrity and does a number of calculations etc.

Running that procedure takes some time, and it is nice for the user to be able to run that in the background as well.

-Nils

[Dennis_Knutson]

Then making them reentrant makes sense. I suspect that the vast majority of users are doing things sequentially as rolf says. However, I would recomend you go to the Product Suggestion Center so that your request can be offically logged.

[rolfk]

---

Nils Gokemeijer wrote:

Exactly, I am running two separate connections.

Let me give you an example: I have a table of values on my front panel. Then I allow the user to change certain values in the table.

Each time the user changes a value one connection updates the value in the database.

At the same time, I have a second connection that refreshes the table from the database in the background. By making the vis reentrant I was able to do this seamless to the end user.

Now that I just upgraded to 8.6, I found out how much this affects my program, because the new toolkit is not reentrant, and I remodified the vis.

Another example is a fairly long saved procedure in the database that verifies the database integrity and does a number of calculations etc.

Running that procedure takes some time, and it is nice for the user to be able to run that in the background as well.

-Nils

---

And I would wager this is not te typical use of the database toolkit. So should all the others take a resource hit to accomodate you or should you rather customize the Vis for your specific advanced use?

Rolf Kalbermatter

[Nils_Gokemeijer]

What would you like to wager? Sixpack or just a pint of beer?

It is nice that NI hasn't password protected these files, so that indeed it is quite a simple change for me to make them reentrant.

-Nils

[rolfk]

---

Nils Gokemeijer wrote:

What would you like to wager? Sixpack or just a pint of beer?

It is nice that NI hasn't password protected these files, so that indeed it is quite a simple change for me to make them reentrant.

-Nils

---

If they would password protect them they would really kill the business for them. There are several other free, both as in beer and code, alternatives out there.

Rolf Kalbermater