Database Connectivity VIs Execute Slowly With Multiple Database Connections

Updated Dec 11, 2023

Reported In

Software

  • LabVIEW
  • Database Connectivity Toolkit

Issue Details

  • I am using the LabVIEW™ Database Connectivity Toolkit to connect to multiple databases. My initial database connection works, but when I connect to multiple databases, the toolkit VIs take several hours to execute. Why does this happen?
  • When I create multiple database connections in LabVIEW, the DB Tools Select Data VI hangs. How can I fix this?
  • When I try to select data from several databases in LabVIEW, the Database Connectivity Toolkit VIs are blocked from executing. Is there a way around this?

Solution

The Database Connectivity Toolkit VIs are non-reentrant. This means that only one instance of each VI can execute at a given time. When communicating with multiple databases, the Database Connectivity Toolkit VI must complete it's operation with one database before it can execute for the next database.

This issue can be avoided by creating a copy of the VIs and modifying their reentrant execution. Follow the steps below to achieve this:
  1. Navigate to C:\Program Files (x86)\National Instruments\LabVIEW <version>\vi.lib\addons\database and open the NI_Database_API.lvlib file.
    • This is a LabVIEW library file containing all of the Database Connectivity Toolkit VIs.
  2. Follow the remaining steps in How Can I Edit and Move Libraries in vi.lib to a Different Location?  to create a copy of the library.
  3. From the copied library, open the VI that requires modifying.
  4. Press Ctrl+i to open the VI Properties window.
  5. From the drop-down menu, select Execution.
  6. Select either Shared clone reentrant execution or Preallocated clone reentrant execution.
  7. Save the VI.
  8. Multiple instances of the modified VIs can now execute simultaneously. 

Note: Reentrant execution only affects the outer-most VI. If the modified VI contains sub VIs, the sub VIs may also need to be changed if you notice that the VI is still being locked by another execution.