I’m currently trying to export some data into excel and I’m running into a couple issues.
I’ve created a couple lists for model changes, and created sub-lists to break them up.
But when I try to use the Data.ExportToExcel node, I just get a Warning saying “Warning: Data.ExportToExcel has failed”. I’ve dug around some forums and checked some videos and see other peoples Excel export node doesn’t have the “WriteAsString” input where mine does but its just a boolean that’s default to False. (Tried False / True).
I’ve seen a few people mention it can be due to windows updates and to try the XML Export instead which has a boolean ouput instead of data, but it doesn’t do anything and doesn’t open the Excel file upon running the script. Then when I try and open the Excel file manually I get an error message and that the file needs recovered.
Just opened the excel file and it seems that changing the file path to a string sorted it with the Data.OpenXMLExportExcel node instead of the Data.ExportToExcel Node. But when I open the excel file after running the script it asks me to recover the file and I get this error report:
Yea I tried a couple different excel files, and no excel isn’t running in the background from what I can see on task manager.
It seems to have completed the task now I have the excel file with the information I need, but I’m not looking to have to check an error report every time I want to run the script. Might dig round and see if there are other ways I can do it, thanks
Hi Andrew i know this is an old topic but with no solution yet provided. Did you ever find the cause of this corruption? I am using the open XML export node to populate an existing excel template file. However i get the same error.
Hi @jm_cop_de Thanks for reaching out and bringing this issue to our attention. We took a quick look and we found nothing that was obvious, so we’ll need more time to explore deeper and figure out why this is happening.
It would help us if we had some more information. Do you get this error when you export to an excel workbook which doesn’t have a pivot table? And is the data that is exported from dynamo used by the pivot table?
Hello Achintya,
thanks for the reply. When I remove the pivot table worksheet beforehand, the export works with no corruption. Attached is the template file I am trying to export to. TEMPLATE_XXX_Sheet_List.xlsx (28.2 KB)
BTW previously we used the Bumblebee exporter for some time with no problems. I am switching to the ootb Open XML exporter to better future-proof our scripts and given the earlier problems with MS Office updates.
@jm_cop_de It is a good strategy to use ootb nodes for future proofing the scripts.
Thank you for sharing this with us, very helpful for us! We will look into this and get back to, so you can use the OOTB Open XML nodes.
Achintya, I suspect the problem with the exporter has nothing to do with Pivot tables but the existence of duplicate values in any cell within the existing template file regardless of if it occurs in a different worksheet. So I have done some testing and have found within a separate script and template file that when a column header in one worksheet is the same as a column header in another then the corruption occurs. When the duplicate value is delete or changed then there is no longer a corruption. Could you test this from your end?
Yes, you are right. I was able to reproduce this when the data being exported has a string. I did not seem to get any errors when the data is just integers. Thanks for helping us narrow down the issue. We will explore this further.
Was this ever fixed? I’m on C3D 2026.2 and when I try to use the Data.OpenXMLExportExcel node then I get the same corruption message in Excel on open. It also deletes many of the cell contents.
My data contains many values with commas, so I can’t use the Data.ExportCSV option and now I’m stuck not being able to export to something I can use in Excel.
EDIT: I deleted the XLSX file completely that was on ACC and reran the graph. It seems to have fixed the error!
Paths to a file on an ACC location provided by desktop connector is not the same as say a path to a file your desktop, so you can’t write directly to them programmatically. Access has to be routed though a mess of files of services to make sure that data isn’t lost by concurrent access or other issues. As such the recommendation is to make the changes to a local file and when complete push it to ACC via DTX, the web interface, or other tool which is built to take those into account.
I am saying that WINDOWS (which is the root tech that this node calls) doesn’t write files to [BIM360 Teams, BIM360, ACC, Forma] the way needs it to as windows deals with files differently than [BIM360 Teams, BIM360, ACC, Forma] (or really AWS since that’s what ACC is built atop - but this is true for any cloud service). As soon as someone else takes ownership of the file you deleted you’re apt to get back into the same problem state you’re in now. To fix this you’d have to lobby the [BIM360 Teams, BIM360, ACC, Forma] product team (not the Dynamo team as they don’t own the [BIM360 Teams, BIM360, ACC, Forma] apis) to add nodes for reading and writing files to Dynamo, likely via a package.
All I know is that I have a Dynamo graph that is using the Data.OpenXMLExportExcel node to write to a file that’s located in the cached folder for ACC that Desktop Connector syncs. I know it’s not writing directly on Autodesk’s servers. But are you saying that using a Dynamo filepath that’s for an ACC folder isn’t supported?
In this case, I deleted the XLSX file that I had been using and now the graph writes to the file. I didn’t change the path. Was the reason it created a corrupted XLSX file because it was on ACC?
It’s more likely that Dynamo reads and write the data faster than DTX is designed for as it doesn’t go thought he checks that DTX performs before trying to synch up the file. The write access issue is also a known thing where eventually DTX marks the file as ‘in use’ by you or anyone else on the hub, which prevents saving over the file. This can even be in the same graph if you read (first copy of the file in memory) and then write (new copy of the file with additional data). All Dynamo nodes which write to a file don’t take that stuff into account as they aren’t designed for it; and as the desktop connector API is private we can’t really work around it on our own, and rolling it into core would expose the private APIs to the world via the Dynamo github so that’s also unlikely to work.
No - I am saying that the ACC path isn’t a real path. Everything you see synched on desktop connector isn’t a ‘normal’ file. All of that only becomes clear if you really look into how DTX works, but effectively the installer modifies the UX for all things windows explorer. When you poke at those files programmatically you’ll find that if stuff is viable or not is a coin flip. This is also why the Autodesk tools which access stuff off the respective clouds wind up doing a LOT more than what they do with windows.
Is it silly that this is the case? Sure.
Is it something Dynamo developers, graph authors, or power users can fix? Sadly not.
The team that can fix assure this type of problem doesn’t resurface is the Desktop Connector team, so requests to get it addressed need to go to them if you want it changed. As far as I know, this is the best way to do so.
My recommended work-around until there’s such capability is to save and read the file off local disc, and then copy to the DTX location when you’re with the export. It’s a pain, but it’s the only foolproof method I found before I gave up with DTX entirely and moved to alternative solutions.
I’m still confused. Dynamo is writing to a file that’s on my C drive. DTX just monitors that folder and if a file is changed it syncs that with what’s on Autodesk’s servers. Are you saying that DTX will do something to the file even during Dynamo’s write that ends up corrupting the file? That in essence is saying that Dynamo won’t work properly with Forma (ACC). And Autodesk should state that in a readme or other materials.
Thanks for reaching out and bringing this issue to our attention. We took a quick look and we found nothing that was obvious, so we’ll need more time to explore deeper and figure out why this is happening.