Labview 7 corrupted a *.LLB collection of VI's

[AKA_TG]

I developed a fairly complex Data acquisition on a new Dell computer with Win2000 professional. I was using the *.LLB option to save my sub VI's. WHen I was copying and pasting the contents of a fairly complicated sequence structure to another frame Labview crashed and apparently deleted my 2 days of work. All attempts to recover the LLB failed. Obviousl;y since then I am reluctant to use LV vers 7 until I can be assured this will not happen again.

[Albert.Geven]

Are you using a ntfs or FAT32 as the filesystem?
Anyhow it is better to develop (any labview version) without llb's. Subdirectories allow nicer hierarchy structures anyhow.
The FAT filesystem has leaks in it and they show up with large files and operations on large files first.
Each update of a vi in an llb is reading and writing and shifting a lot of data in the .llb file. So file errors occur much faster than in normal subdirectories where only the vi is updated.
We use lv7 now for a while and it crashes not more than the previous stable versions.

[AKA_TG]

WIn2000 Pro Service pak 4
I do not think it is FAT 32. The disk access is slower. I do not know how to check this.
Anyway although I have LV7 and have learned not to use LLB's (doh!) I still am reluctant to use ver 7 because the prior problem I described was so serious and beyond anything I have ever encountered. FYI im using identical computer hardware and OS with 6.1.1 for many months on a large app with no probs.

ALthough I can't be more specific I believe this has something to do with replicating a sequence frame having a fairly large number of controls and arrays on it.

[Albert.Geven]

If you click on properties of your drive (explorer) you can see the file system mentioned somewhere in the top of the property pages.
I don't believe it has to do with sequence frames and so, maybe the crash is related to too many controls but I don't believe this. It happened for sure during fileIO otherwise your .llb was not corrupted.
Big chunks of code give a lot of infile moves with a .llb. I'm still interested if it is a fat32 or ntfs file system.

[Jeremy Braden]

I believe NI has an experimental utility for recovering VIs from a corrupted library. You may want to contact NI directly. This way you might recover some of the VIs you saved.

[Andrew Madry]

I had the same problem as in the question with LabVIEW7 and the same computer configuration in the question. While in a LabVIEW7 session the machine locked up intermittently. After rebooting the llb was corrupted. There is a utility available for recovering a corrupted llb. I found that it was able to recover everything except the top level vi (I think). On another Exchange posting I found another suggestion and that was to look in LabVIEW's temporary directory ie Options-> Path-> Temporary directory. Look in that directory and you will find vis or llbs with strange names. One of them is likely to be a temporary version of the program. Look for one with the same size as the corrupted one. I was able to recover my program this way.

I have
gone away from using llbs because of the danger of corrupting the whole thing.

For interest I found out the reason for my computer crashing.Our friendly NI rep asked if I was using a FIRE GL graphics card (which I was) and suggested updating the graphics driver (must have known something I didn't). There were at least 20 updates of the driver in the 6mths since I bought it. The machine hasn't crashed since.

regards

Andrew Madry

[crelf]

I agree with Andrew - llb's were originally devised to overcome the cross-platform issue of long file names (they also do a little compressing). These days, most people use sub-directories, and they're easier to navigate, and more friendly to system backup software.