activity-browser
activity-browser copied to clipboard
Excel exporter bugs
I ran into an error message when exporting a database to Excel. The error emerges because the exporter needs to export a cell with a date. I was able to solve it by making 2 changes in the code.
In \xlsxwriter\worksheet.py", line 531-532:
s = str(token)
return self._write_string(row, col, s, *args)
In activity_browser\bwutils\exporters.py", line 100:
sheet.write(row_index, col_index, frmt_str(value), frmt(value))
Hi Sander, Could you point me to where the exporter actually needs to export a date? Or does Excel just assume something is a data which it is not? Also, could you share the full path to the top file? I don't recognize from the code where it would be.
Anyway, thanks for helping fix the issues you find!
Hi Marc,
The fields with a date originate from CMLCA, which assigns a creation date to processes. This is exported as one of the process properties.
The full path is: C:\Users\username\AppData\Local\Anaconda3\envs\LCA\lib\site-packages\xlsxwriter\worksheet.py. I realise that this is part of Brightway2, so I might contact them as well.
That library is not part of our or Brightway code, but from the xlswriter library.
Perhaps this is easier to resolve by skipping the creation date field on import as AB does not use it. If we would store the field though, I think it could be better to keep the Excel timestamp format and make AB understand that instead of making it a str (which I think your code does, right?).
@bsteubing What are your thoughts on date import/exports?
No, I'm not proposing to store it as a string. I'll explain a bit more what I noticed in the existing code.
The xlsxwriter has a _write function for multiple data types. It selects one automatically when you call sheet.write(). However, the ActivityBrowser calls directly to only two methods: write_string' and write_number`. This approach fails with a date.
Therefore, I propose that ActivityBrowser uses the general write() function. This only works if the xlsxwriter works as expected, hence my second suggestion.
Thanks for the additional info, what I don't yet understand is why there would have been a change in the xlsxwriter lib? If all we need to change is our code, I'd be happy to help you submit the change or make the change for you to our code!
We can't start making changes to the xlsxwriter library, for the moment though we can use the more generic/general write() function and start to make progress from there.