LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

database: compact and repair fixes broken vi's

I've written an application that makes use of the Database Connectivity Toolkit. It's been up and running in proper fashion, writing to and reading from the database.

 

Until a very strange thing happened...

 

We shut down the application as we'd done several times before, but when we re-opened the app, it was broken. All of the DB Toolkit VI's were broken. We messed around, browsing thru them to find what was broken, but all we could find was that they were broken for no reason. I considered removing and re-installing the toolkit, but decided to save that for a last resort. Somewhere in the process, we happened to do a Compact and Repair operation on the DB. Lo-and-behold, the next time we opened the application, the VIs were runnable again!

 

We tried to duplicate the broken-ness by opening and shutting the application, but could never get it to repeat. Until today, when I am of course not on-site to do anything about it. This time however, the Compact and Repair operation did not fix the broken VI's. We're going to do a rollback on the database to a backup they'd recently made to see if that corrects the situation, but I hate to hope that it solves it. This type of thing just shouldn't be possible, at least from everything I understand about how LabVIEW works.

 

How can an application work, be shut down and re-opened, and then not work?

 

And, how can Compacting and Repairing the database miraculously fix the DB Toolkit VI's?

 

I'm absolutely stumped on this one.

 

FYI:

 

Software Versions:
  - OS             XP SP3
  - LabVIEW        8.5.1

  - MAX            4.3.0.49152
  - FP             6.0.0.3003
  - DB Toolkit     1.0.132
  - DSC Toolkit    8.5.0
  - MS Office      2002

0 Kudos
Message 1 of 4
(2,313 Views)

a.winslow, 

 

I am sorry to see that you are having these difficulties with the Database Toolkit!

When you say that the VI's were broken, do you mean that each subVI had a broken "run" arrow?  Or that they malfunctioned while attempting to communicate with the database?  Is there a particular error message or code you received?

Matthew H.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 4
(2,276 Views)

The VI's had broken run buttons.

 

It was especially weird that we had just been running the software, shut it down, and brought it back up and they were broken. This has happened on at least 3 separate occasions. Two of those times, performing a Compact and Repair operation on the database from within Access seemed for whatever reason to fix the problem. This most recent incident required a rollback on the database for the VI's to open in a runnable state.

 

By the way, when I say we shut down the software, I mean we closed all VI's and exited LabVIEW prior to re-opening them.

0 Kudos
Message 3 of 4
(2,269 Views)

That is pretty Bizarre.

 

I've uncovered a couple bug reports about this sort of thing occurring in LabVIEW 8.5, but only when there was a property mismatch or wrong class being selected by a property node.  I don't imagine that is what is occurring in your case because the problem is not occurring with any regularity.

 

I know that when a Compact and Repair is performed, some file permissions are reset to their default values, but I am not sure under what circumstances that sort of thing would be parsed by the VI before the VI is run.

 

I'll keep searching to see what I can turn up.

 

If it happens again, try running one of the broken VIs to see which connections are upsetting LabVIEW.

Matthew H.
Applications Engineer
National Instruments
0 Kudos
Message 4 of 4
(2,260 Views)