Whats your opinion on this? I can see why both might be good. If you think I should just move the records aside instead of delete, do you know of a way to compress the data for those records so they don't take up as much storage space?
Whats your opinion on this? I can see why both might be good. If you think I should just move the records aside instead of delete, do you know of a way to compress the data for those records so they don't take up as much storage space?
We have a substantial amount of data being synchronized from field data on the front end interface. The data is often 'deleted' from the users point of view, but internally I am actually storing the 'deleted' data into a "Inactive" table for research in case of user mistakes or user wanting of the data back.
To make this piece of "Inactivated" data have any significance, I have also added user fields and date fields which the user does not see to determine when and who 'deleted' the record in case of any training issues or reversal of the process.
I have found that actually deleting data can leave you feeling as if you have also lost some potential research as to why the record was deleted.
Of course you can always purge out data once you have determined there is actually no need for it.
Hope this helped.
Naeem~
Yes, that helps very much, thank you!
If your db size is reaching the 2GB limit for Access, deletion of data might be an option but should be done only if absolutely no other approach is feasible and you really will never, never want to see it again.
An option is to split db into front and back ends. If that has already been done, then can split the backend into multiple files the frontend links to. Or upgrade to MySQL or SQLServer.
Regardless, the Access files should be Compacted and Repaired periodically.
How to attach file: http://www.accessforums.net/showthread.php?t=70301 To provide db: copy, remove confidential data, run compact & repair, zip w/Windows Compression.
That makes sense, thanks June!