Error 6 occurred at Open/Create/Replace File in NI_Excel.lvclass:Save Report to

[DEppAtNGC]

I have an application that works on LV60 and when run in LV86 I get the following error: Error 6 occurred at Open/Create/Replace File in NI_Excel.lvclass:Save Report to File.vi->SWF001 Test.vi Possible reason(s): LabVIEW: Generic file I/O error. ========================= NI-488: I/O operation aborted. C:\SWF001 IO Files\1_Single.xls The application does: New Report.vi Excel Get Worksheet.vi Excel Easy Table.vi Excel Easy Text.vi (4 of them) Save Report to File.vi Dispose Report.vi all in a nice chain (errors and report-in/outs) as is typical For some reason I'm getting this error. I'm using it with Excel 2003 SP3 and the spreadsheet contains macros (and I get a prompt "should I enable macros:" (I answer yes), that I didn't get with LV60 and the older version of Excel). This is probably not the problem? but deserves mention. The file does exist on the system (and it appears the application is writing to it successfully - though perhaps truncated as the error indicates- i can't tell for sure). I can open and save the Excel file independently of LV just fine. Any clues? Many thanks! -David

[RavensFan]

Try setting your Security for Macros in Excel to Low.  That should eliminate the dialog box asking if you want to enable macros, and also tell you if that is what is tripping up the file open function within LabVIEW.

[mikeporter]

Unfortunately, an Error 6 is a catch all category for all sorts of file IO errors that LV doesn't know how to handle. For example, while it doesn't sound like your problem, trying to access a file that resides on a network drive that isn't currently mounted can generate an Error 6.

Have you tried saving the file to a different location?

If you restart your computer and run the VI does it generate the error the very first time you run it?

Can you post your code - or at least a subset of it that demonstrates the problem?

Is Excel open when you are running the code?

Also, as a test try modifying your code so it has a unique name every time you save it.

Mike...

[DEppAtNGC]

I tried: Creating an empty "input" .xls file in a newly created directory and hardcoded to use that - no help. Setting security to low so the prompt does not occur - no help. Is Excel open when you are running the code? - no Also, as a test try modifying your code so it has a unique name every time you save it. - THATS IT! So why do I have to save it with a different filename???

[mikeporter]

My guess is that the ActiveX code is not closing the file or shutting down Excel when it finishes. If you don't explicitly stop it Excel will continue running in the background which can cause all manner of weirdities.

Something you might want to consider is changing the way you are access the spreadsheet file. You can also read/write xls files using ADO.

Mike...

[DEppAtNGC]

I'd like to see someone from NI research this further and possibly file a defect report. It worked fine in LV 6.0 with an older version? of Excel.

[mikeporter]

That is very likely, but Microsoft has rewritten the Excel interface at least twice since V6 was current - which is why I like to avoid the whole issue and use ADO to interact with Excel files. It's even faster...

Mike...

[Karunya_R]

Hi Deppangtc,

You have an interesting problem. I would like to see some files so that I can replicate your problem here. Which version of LabVIEW and OS are you using? Have you noticed this in previous versions? Or with any other versions? Were you able to get this working properly in older versions?

Mike,

Thank you for your solution and suggestions on this one!

[DEppAtNGC]

Hi Karunya, Thanks for your help. See above for LV & Excel rev. It's on Windows XP. No other versions besides those mentioned were tested.

[Karunya_R]

HI Deppantgc,

I requested your files because that would make the problem replication smoother. In situation like these, there are few triggers and circumstances that cause the error message to happen. In order to replicate the problem, it is, often, best to start with the file that causes the issue. This way, I can use your files, replicate the problem and test it out on different systems. If you can post what exactly your application does and the files themselves, it would be easy for me to file a report/research this further.