I would like to request that this be put in the ideas category.
Like a number of other people who have started using attachments, I am concerned about the disk space usage of attachments causing the Manager database to balloon.
Yes, the sqlite database in theory could support a massive database size but I believe that the current attachments database storage design is fundamentally flawed for the following reasons:
If you are using desktop manager, and you wish to email your account the database to do end of year returns, this will become a problem if you are emailing all the attachments as well. Sending a 50mb email is not practical. This point alone renders the Attachments functionality useless.
If you are using the cloud storage version of Manager, this will cause quite significant space usage costs for the service provider compared to the size of the Manager database without attachments if there is no ability to delete obsolete or inactive attachments.
With the advent of GDPR, it has encouraged people to think about how long we want to keep information for. I can foresee that it might be desirable to delete attachments older than say 10 years on the basis that it is extremely unlikely that you will ever want to view an attachment older than that. The invoice etc will still remain obviously. This would help to optimise the database in terms of size, usefulness of information etc. I think that there needs to be some kind of database management tool kind of like you see in WSUS where you can remove obsolete attachments (older than x years) or remove pictures from inactive inventory or any inactive entry.
Would it be possible to redesign the attachments storage with the following in mind. Enable a backup without attachments thus allowing users to send accounting files to accountants. In addition, to include database storage management functionality to delete obsolete and inactive attachments as described above.
Ability to make backup without attachments will have to be implemented.
Eventually I want to implement purging function so you can delete all transactions before certain date - this would delete associated transactions too and re-establish new starting balances.
These two additions would solve your concerns regarding attachments. I don’t think the current implementation is flawed, it’s just that it’s not complete. The foundation is good.
Perhaps flawed is a strong word. I will go with incomplete. I am glad that you agree with my two points.
Good to hear that you will be implementing the ability to make backups without attachments as this will address the biggest problem.
I agree that a purging function is required. I am not sure that I see the logic of deleting say invoices older than ten years. Yes I will probably never ever use an invoice older than ten years, but I can foresee unintended consequences in deleting transactions before a certain date.
As these records, say an invoice take up practically zero hard drive space at all, is there any benefit to doing this? Removing old attachments makes sense because of space usage build up, but old transactions take no space.
I would recommend a purge based on data that takes up hard drive space and just ultra compress older transaction data?
One thing that I can think of is say doing a report on the growth of the business over a 20 year period to see if recessions affect business growth or any kind of report where you want to look at the business over a much longer period than say ten years.
Purging transactions older than x date would affect reporting functionality as an unintended consequence. Just a thought.
!. Perhaps an [Archive attachments] option when doing a backup?
2. And, there’s always good old Winzip or WinRAR. This will compress the file significantly for emailing purposes.
The issue is not just the file size when emailing. The attachments most of the time do not need to be emailed, therefore it does not make sense to include attachments when creating a backup that you want to email. Winzip, 7Zip etc are good tools but they won’t be able to compress the documents by much, its more effective for pictures.
Most people have a backup program that backs up their entire data structure including manager. We only use the backup to send a copy of the file to someone. Therefore it would make sense to archive attachments within the program in the manner that the developer suggested. But he will decide how he wants to implement this.
Agree as long as the ability for a full and complete backup with attachments is not discontinued. However our current automated backup regime includes the data path so the expectation is that the attachments will always be included in the backup. Should there be any changes to attachment location and or where they reside we will need to be updated.
The ability to make a backup which includes attachments only after a user specified date would be most useful for me.
That way when sending a copy of my records to my accountant I can include just the relevant financial years attachment. Similarly I could move to a data file without attachments older than 7 years (financial records not legally required) should storage be an issue.
Mass deletion of information is a dangerous feature to support. I would prefer a work flow which forks the data file so the old complete data file is moved to a long term backup location and the new pruned data file is actively used.
Your suggestion has merits and reflects the point that there are many ways to handle archiving attachments.
I agree that including the current financial year’s attachments for the accountant for end of year returns does have a lot of merit and I would find that useful for my accountant.
Yes I agree that mass deletion is fraught with perils which is why I don’t support purging older transaction data because they are useful for reporting etc. However, it is extremely unlikely that anyone will ever need to view the actual supplier invoice after say ten years so my preference would be to purge the attachments data to be consistent with GDPR. Although its not GDPR applicable as there is no personal data here. But the principle applies. I no longer need that data. I don’t want to go down the route of archiving databases and then be unable to open the database ten years later because Manager has changed too much. It can happen.
Why can’t we have migrate data without attachments to new database? at the same time backup the previous database as archive then purge in the process? There should be a script that can execute at one go and at the end of the process you have both migrated database without attachment and archived backup data to be saved.
