You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 1, 2022. It is now read-only.
If an unhandled error occurs half way through exporting, then the user can be left in a situation that could result in data loss if they're not careful. The problem is that only some of the modules have been exported to the file system and have been deleted from the VBAProject. This leaves the user in a situation where they do not have a complete copy of their work in a single location. The export action will not work with only some of the modules in the VBAProject, it will raise an error. And even worse, if they use the import action, they could potentially overwrite work done to the modules which didn't get exported. Currently the best way to recover from this is to manually either export the remaining modules or import the missing modules.
Clearly it would be ideal if no unhandled errors occurs, however that is not possible to attain since some things are out of our control. An extreme example would be an immediate program interruption (think power outage).
So instead, I propose that the export action be done in two steps. The first writes the files to the file system, and when that is successful, then delete the modules from the VBAProject.
An alternative (or compliment) to this would be to allow the export action to be successful with only some of the modules present. Perhaps a warning can be shown in this situation.
The text was updated successfully, but these errors were encountered:
This has happened to me in the past, not by power cut but by dodgy code, my fix: close Excel don't save anything 😄
I haven't really considered it until seeing this but think that what you have suggested should work, only clear out the workbook once all modules have been exported, if it fails mid way through then there's no issue as the code will still be in the workbook.
If an unhandled error occurs half way through exporting, then the user can be left in a situation that could result in data loss if they're not careful. The problem is that only some of the modules have been exported to the file system and have been deleted from the VBAProject. This leaves the user in a situation where they do not have a complete copy of their work in a single location. The export action will not work with only some of the modules in the VBAProject, it will raise an error. And even worse, if they use the import action, they could potentially overwrite work done to the modules which didn't get exported. Currently the best way to recover from this is to manually either export the remaining modules or import the missing modules.
Clearly it would be ideal if no unhandled errors occurs, however that is not possible to attain since some things are out of our control. An extreme example would be an immediate program interruption (think power outage).
So instead, I propose that the export action be done in two steps. The first writes the files to the file system, and when that is successful, then delete the modules from the VBAProject.
An alternative (or compliment) to this would be to allow the export action to be successful with only some of the modules present. Perhaps a warning can be shown in this situation.
The text was updated successfully, but these errors were encountered: