Error -2147467259 occurred at Exception occured in Microsoft Excel: Document not saved.

[DLMC]

Windows 10 Enterprise

Labview 2017

.exe distribution

MS Office 365 Version : 18.2306.1061.0 (on Dev and Target computer)

I have a LV program that builds and Excel sheet, saves it as a PDF and then offers between displaying the pages or printing them.

The Excel bits that create the Excel work fine. Everything works fine on my development workstation but fails on the target computer.  I can't debug on the target computer since it does not have LV on it and they get it as a .exe, so I am flying blind trying to troubleshoot it.

I have read the forums that I have found about Report Generation Toolkit and "WorkIdentity" issues, such as:https://forums.ni.com/t5/LabVIEW/Save-report-VI-from-report-generation-toolkit-is-broken/td-p/336224...

None of the suggested fixes worked. 

However, one of the fixes recommends the method SaveCopyAs instead of SaveAs - my code was written with the method ExportAsFixedFormat, type = PDF, not SaveAs, and there is no SaveCopyAs method.  I've rebuilt the vi, done a Mass Compile, everything suggested. 

It doesn't seem to be permissions either, I tried running it as Administrator, same problem.

It is the same version of Office on both systems.  My problem must be different because unlike the others, I have the exact same version of Office 365.  Something else must be getting in the way.

The file is not written where it is supposed to go on the target system, but it is on the development system.

This is the screen I get:

Has anything new been discovered since 2017?  I am not very experienced with LV nuance, having only learned it 5 months ago, and on top of that, I am updating a program written by someone else back in 2019.

I have attached my vi below.

Any help is appreciated.

be well,

DLC

[DLMC]

Found that the free 3 of 9 extended font was not in the system fonts on the non-working machine.  The spreadsheets now look correct, but sadly, this too did not solve the issue.

I installed NI 2017 on the target machine and transferred my license there to debug, but that wasn't any help, the Invoke Node just returns the error, no new information gained.  But, easier to test hacks.

Because the Oracle client needed to be installed before this code could work and the free 3 of 9 extended font needed to be separately needed installed, this strongly implies that some other things had to be installed for this code to work.  I don't see an install list anywhere, so it was probably tribal knowledge. 

Still trying to get something that "just aughta work" to work.

be well,

DLC

[DLMC]

In the spirit of messages to the future...

I found the install list of things to do, and have done all of them.

Install Oracle client

Install bar code font

Give "full control" to the folder with the template files

Install this .exe

But, still, no dice.  Still searching for more hacks to solve this.  I will post any progress.

be well,

DLC

[DLMC]

Well, more frustration.

I tried to use SaveAs, but it gets a similar error as ExportAsFixedFormat.  Both have the WorkIdentity field in the InvokeNode.  SaveCopyAs does not have the WorkIdentity, but it doesn't save as a PDF file, and no way to tell it to.  A recent MS update caused all the rest of my computers that used this code to fail now.  So, the only program using this vi to export a worksheet to PDF is one that was created in NI2010 and is running on a Windows 7 box that does not get IT updates.

I have tried every solution given, right down to rewriting the vi from scratch. 

Interesting, I can save it as an Excel file with SaveAs, but not as a PDF.  It seems to be something directly related to PDF files.  Maybe an add-on is needed for Excel?

Still welcoming ideas...

be well,

DLC

[DLMC]

More to the saga.

According to this NI link:

http://digital.ni.com/public.nsf/allkb/C9408B9F08D711E786256F3300701D01

There are certain versions of Labview that work with certain versions of Office.

I am developing on a system that uses NI2017, which works with Office 2016, but not Office 365.

At some point, I assume recently, an update caused the Office 2016 exe's to be replaced with Office 365 exe's on my development computer.  If that is the case, and that compatibility matrix is correct, then my code cannot work.  And compiled builds (for an exe distribution) will also not work on a system using Office 365.

An oddity that I found however, is that Python code written with COM calls to Excel on my computer also fails at the same point when exporting PDF to a file.  This means that everyone's code links to Office apps is broken until updated.  That isn't nice.

be well,

DLC

[DLMC]

Notes and confirmations.

The Office 2016 (32 bit) executables were changed on 9/26 to be Office 365 exe's.  This jives with when my LV code started throwing errors unable to write PDF files.  At the same time, the same thing happened on the operations computers with LV 32 bit code using Office 2016 64 bit code.  That is the smoking gun.  NI2017 apparently doesn't work with Office 365, so this must be one of the things that goes wrong, maybe?  Or maybe, NI2017 was never tested with Office 365.  Regardless, this appears to be the cause of the problem.

However, NI2022 also does not work with Office 365 (64 bit in my case), with the same symptoms.  The compatibility matrix referenced above, stops at NI2021, so anything past that is going to be an assumption.

Because NI2017 doesn't work with either Office 365 32 bit nor Office 365 64 bit, and NI2022 does not work with Office 365 64 bit, I am left with the assumption that no NI version works with Office 365 (32 or 64 bit) even now, for PDF export/saveAs.  But I do not have any other system with Office 365 32 bit on it to test this assumption.  Can anyone confirm that NI2022 Report Generator will export or saveAs PDF an Excel file with Office 365 32 bit?

I have a support ticket in with NI about this, and are looking at it, but I have no definitive answer yet.

be well,

DLC

[DLMC]

Update.  NI suggests that you can't use NI2022 32 bit with Office 365 64 bit, so that is the problem.

This is incorrect, that combo works fine.  I've attached the vi that is failing, but instead of using the Report Out from all of the work before, I created a Report Generator output that is just a template file and sent that to my suspect vi.  It works fine.

SO, something changed in the RG generated spreadsheet before this point that causes a file save to fail in this vi.

be well,

DLC

[Bob_Schor]

I have been using the Report Generation Workbook with Microsoft Excel for at least a decade.  These have included the following "bits and pieces":

• 64-bit Windows OS:  mainly Windows 7, 64-bit and Windows 10, 64-bit.
• 32-bit LabVIEW (Full and Professional), from LabVIEW 2014 to LabVIEW 2021 (I'm mostly using 2019 right now).
• 64-bit Microsoft Office, from Office 13 and Office 16 to Office 365, which seems to be Office 2019 (can't seem to verify whether 32-bit or 64-bit).  [Well, I just spent about half an hour trying to find out that the version of Excel on this PC is, in fact, 32-bit.  Sigh, why did the Enterprise do this to us?]

I've done a fair amount saving LabVIEW data into an Excel Workbook (with multiple WorkSheets).  I haven't tried to do "fancy" things like printing to a PDF, but have done "data application" involving the Workbooks (like saving "raw data" in one WorkSheet and using these data to create other WorkSheets with histograms and other "data analytics", including plots, on other WorkSheets.

I have noticed in going from one version of LabVIEW to another, and from one version of Office to another, that there have been "compatibility" issues as Microsoft adds new properties to the Excel Objects, but these have generally been easy to fix.  However, this does mean that you need to "manually" check that your LabVIEW and Office versions are compatible, easiest to do if the Development and Deployment PCs have the same version of Office and Windows.

Maybe it would be helpful (for us trying to advise you) if you sent a "simple" example of an Excel Workbook and a simple LabVIEW routine that fails when working with this Workbook.  If we can "get it to work", we might be able to get you over this snag.

Bob Schor

[DLMC]

Bob,

Thanks for the support.  The simple case vi I attached in the last post, actually works.  I have not found a simple setup that I can get to fail.  I am going to attack this with a debugging session tomorrow to see if I can understand what went wrong with the worksheet manipulation to cause an error.  If I can stop the program before it tries to print, I can save that file (.xlsx saves work fine, only PDF saves don't) and try to manually duplicate the error.

At this point in time, there are too many independent variables floating around to make a call.  I will post more details, and if I don't solve it, maybe a simple self-contained vi that shows the problem.  <fingers crossed>

be well,

DLC

[DLMC · Accepted solution]

I found the answer - The NI tech support folks gave me the hint that led down the path to discover.  (Thanks Grettel)

This is not a Labview issue, it is all about Office 365 and the Excel .xlsx format.  I will not go through the torturous set of experiments that got to the answer, I'll just give the answer.

Office 365 will NOT saveAs PDF from any .xls file.  Period.  If you are creating a new .xlsx type Excel file, you are required to supply a "sensitivity" setting (I think your organization stipulates this sensitivity requirement).  But, you still won't be able to save the PDF if this is a new .xlsx file that doesn't have the sensitivity set in it.

So.

The way to get around this is to only use .xlsx templates for your Report Generator that have already had their "sensitivity" level set.  This will carry through - And never use a legacy .xls file as a Report Generator template file.

And yes, your 32-bit Labview vi can "Invoke Node" a 64-bit Office 365 app.  You may need to register the API with Labview though.  This knowledge base shows you how:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019KZNSA2&l=en-US

be well,

DLC