Running on an Azure virtual remote desktop could be the issue. Is Excel installed on the same host instance(s) as Sage 50 Accounts in Azure, and if so is it the 32 bit version of Excel that is installed?

Excel is on the same instance as the Sage Accounts app, and it is also a 32-bit version. The setup on the virtual Azure Windows 10 desktops is the same as on our working physical PC's. 

What is strange is if we instead click on Reports on the menu at the top, we can select any report which will send to Excel. This always works fine. How is this different to the Send to Excel function?

Thank you for your time to assist, it is appreciated.

The implementation of those two features is quite different behind the scenes (largely for technical and historical reasons). The reporting method of sending to Excel generates a temporary file using the OpenXML document format and launches the file. The 'standard' send to Excel function uses the Excel COM API to generate an Excel document in memory and populate it with data from the grid.

The "Failed to connect to Excel" error message only happens in one circumstance, when the Excel Application COM server cannot be created.

On the Azure instance that is running Accounts try opening a command prompt and running the following command:

reg query HKCR\Excel.Application\CLSID

Make sure that you are doing this as the same Windows user who is normally connected when running Accounts. 

Does that command return a CLSID or an error message?

If it does return a CLSID then try running the following (replacing YOUR_CLSID_HERE with the value from the result of the first command):

reg query HKCR\CLSID\{YOUR_CLSID_HERE}\InprocServer32

Does that return any detail or produce an error message?

Thank you, I will let you know how I get on.

Hello, 

Sorry for the delayed reply, we have been moving offices and it’s been chaos. 

Your kind solution does not seem to have worked for me. In entered the command as you state… 

                reg query HKCR\Excel.Application\CLSID 

…and it produced this… 

I assume the numbers there are the CLSID that you say I should enter with the next command. So I entered this… 

reg query HKCR\CLSID\{00024500-0000-0000-C000-000000000046}\InprocServer32 

It produced this…

I then ran Sage Accounts, and tried to “Send to Excel” again but it still says “Failed to Connect”. 

Have I done this correctly? If so, how else can this be fixed? 

Thank you. 

Bruce

Just to be clear those commands were not intended as a fix but rather as a check on the same thing that the Accounts code is looking for when trying to connect to Excel.

The results of those commands do show that Excel is installed so could you run a further couple of commands to confirm the setup please:

echo %platform%

and

reg query HKCR\CLSID\{00024500-0000-0000-C000-000000000046}\LocalServer32

and let me know the output of those please?

Thank you for your quick reply.

echo %platform% just gives "%platform%"

And "reg query HKCR\CLSID\{00024500-0000-0000-C000-000000000046}\LocalServer32" gives...

"ERROR: The system was unable to find the specified registry key or value."

Thank you.

Bruce Lewis said:

echo %platform% just gives "%platform%"

That should definitely return something. Are you running this from a command prompt and not PowerShell?

Bruce Lewis said:

"ERROR: The system was unable to find the specified registry key or value."

That is strange so "reg query HKCR\CLSID\{00024500-0000-0000-C000-000000000046}\InprocServer32" returns data but "reg query HKCR\CLSID\{00024500-0000-0000-C000-000000000046}\LocalServer32" does not?

I'm not an expert with Microsoft Office but it is possible that indicates an installation issue with it. Does the same query on a PC where the Excel integration is working return data? Also what path is Excel installed to? If you run the following command this will find it for you:

where /R C:\ excel.exe

NOTE: It will likely take a little while to complete/return results for that command as it is doing a full search of the hard drive to find Excel.

The command is definitely being run in a command DOS shell. I have also run it on my own laptop with the same result. 

And yes, the "Inproc" version returns data but the "Local" one does not.

Excel is found at "c:\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE"

Unfortunately I no longer have access to a PC where Sage to Excel works. This is because we have had to vacate our office, and we have been let down by the place where we will be moving to. Currently, all of our physical PC's, desks, our entire office is sitting in a storage facility somewhere and we are all having to work from home, using this Microsoft Azure virtual desktop. It works perfectly, except for this Sage to Excel issue. What is strange is if I go to reports it exports data, but I have since found out from my users this is causing other issues, where users cannot import journal batches or send any documents from Sage to clients like remittances. I think the latter is to do with Outlook. But if we can get something fixed, that will be a big help, and hopefully lead onto sorting out the rest.

Thank you.

Very strange that the echo command doesn't work. I've tried it on lots of different machines and had no issues with it. It's not a problem though as the path that Excel is found in confirms what I was after and that this is a 64 bit version of Windows running the 32 bit version of Excel. That is perfectly fine and Accounts should be able to work OK with Excel in that configuration. There is definitely something strange going on that I'm not seeing at the moment and is stopping Accounts from communicating with Excel via the COM API.

Bruce Lewis said:

What is strange is if I go to reports it exports data

The reporting method of sending to Excel works in quite a different manner as it generates a temporary file using the OpenXML document format and launches the file. This is the equivalent of simply double clicking on an Excel file in Windows Explorer and Excel automatically launching it.

Bruce Lewis said:

users cannot import journal batches or send any documents from Sage to clients lime remittances. I think the latter is to do with Outlook

That is interesting as it could suggest a more general issue with the application being able to communicate with Office applications or with the installation of Office itself. I am struggling to see the specific issue though. One clutching-at-straws type of suggestion is that it could be a permissions related issue, and that for some reason the Accounts application is being denied access to the relevant registry keys or necessary DLL files on disk. Probably unlikely but worth seeing if we can rule it out anyway. Could you try running Accounts as administrator - right click on the shortcut on the desktop and choose the run as administrator option. Then see if it makes any difference to the export.