LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Spreadsheet file corrupted

Hi everyone,
 
I have been battling a file corruption issue for a while now. I use the "Read from Spreadsheet File" and "Write to Spreadsheet File" VIs to log data in my program. The data being written is a 2D matrix of n_rows by 5 columns and is in 'string' format. The file is being saved with an .XLS extension (but interpreted as regular text file). What seems to happen after a while (weeks), is that the log file ends up looking like a bunch of NULL characters in a long string. It loses its matrix format. If you look at the file with a HEX editor, the contents look like a lot of 'x00' values (which is not a recognizable ASCII character). In short, imagine there is a file that's for example 5kB in size but consists entirely of 'b0' values.
 
I can't figure out why this happens. The logic in the program is sound 'cause it works for a long time but then SOMETHING happens and the file gets corrupt. It is possible in my code that there could be a race condition between the "Read fro Spreadsheet" and "Write to Spreadsheet" VIs, but I believe (or hope) that the file I/O has been coded in these VIs so that the operations are atomic (or semaphored or something!). Another guess of mine is that maybe this has to do with the PC having the power cut from it in the middle of a read/write operation. This does happen with my system.
 
I don't understand how the whole log file can turn into a series of '0' bits (essentially NULL characters).
 
Anyone else come across this issue or something similar?
 
Any ideas would be appreciated.
 
Thanks,
Mehdi
0 Kudos
Message 1 of 5
(3,035 Views)
It is hard to believe that a file changes its format by itself. Are there all nulls (100%)? Could it be somebody is saving is a "real" xls format after looking at it in excel?
 
can you attach one of the problem files?
 
There was a 8.5 problem that generated null characters instead of binary data, so that's probably not the same.
 
 
Did you scan your HD for errors?
0 Kudos
Message 2 of 5
(3,024 Views)


@mehdi - CV wrote:
Hi everyone,
 
Another guess of mine is that maybe this has to do with the PC having the power cut from it in the middle of a read/write operation. This does happen with my system.
 
Any ideas would be appreciated.
 
Thanks,
Mehdi

If you're losing power in the middle of a file IO operation, that would be my first guess for the corrupted files.

Is there any way you can correlate the power loss events with the corrupt files?

Second guess would be what Christian suggested about some one saving the files in Excel format instead of ASCII format after viewing in Excel.

Ed



Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
0 Kudos
Message 3 of 5
(3,018 Views)
Thanks guys.
 
I have attached 2 files. The first is what a good file is supposed to look like (the text is fake but you get the idea). The second file is the corrupted one.
 
The problem is rather rare so correlating it's occurrence with anything is rather difficult, and I usually don't hear about the problem a few days after it happens anyway. But I agree it would be nice to know if there is a correlation with the power loss.
 
As for the excel read/write suggestion, no one but the program itself has access to those files and the program uses nothing other than the "Read/Write Spreadsheet File" VIs to access it. I have tried opening the files myself and resaving them as excel and while they are no longer usable because excel adds a bunch of things to the files, the files aren't corrupted (even after another read/write attempt by my program).
 
For the two files attached, open them in notepad or notepad++ to see the content. For the corrupt file, if you use a HEX editor, you'll see that it's all x0's.
 
Thanks again guys.
Mehdi
Download All
0 Kudos
Message 4 of 5
(3,005 Views)

I'd still have to say the most likely cause is the power loss.

Try coding up a way to log when there's a power loss. I've done this writing a specific line (Shutdown=Good) into a text file every time the application is stopped in the normal way. The first thing you do when the application starts is to read this file and see if it reads "Good" or "Bad". If it's Good, then overwrite the line with "Shutdown =Bad". When you lose power, the "Bad" will not be changed to "Good" and when you restart, the check that runs first will catch it and you can write the time/date to a log file to show the power loss.

Ed



Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
0 Kudos
Message 5 of 5
(2,974 Views)