My Access database was originally just short in size of the 2GB limit that Access allows. To reduce size, I went through and removed attachments. Unable to find a good automated way of removing all the attached files, I went through and manually removed each attachment by right-clicking each attachment field, "Manage Attachments", and clicked Remove for all files.
I haven't seen a reduction in my database's size since doing this. Is there a step I missed, perhaps? Is there a macro/query I could run to wipe all attachment data from the table I have?
Please note, I need to keep this field intact, just remove all attachment data. Thanks.
Take a look here. You can try putting some of your tables into a separate Access DB and linking them, which will allow you to get around the 2GB limit. Also, set your DB up to compact on exit, which should help to keep it under control.
It seems that Access keeps attachments cache stored in accdb even if you delete records that contains an attachments fields, so you need to make a fresh accdb file, and then import all tables from the accdb you already emptied from attachments
Related
I am working with a vendor to debug an issue with a Lotus Domino 6.5 application. The vendor had originally asked me to make a copy of the application by going to File > Database > New Copy > Design Only, and then to copy some sample documents (with sensitive info removed) from the original database to the new database. But when I copy documents in this way, the views do not display correctly.
I then tried making a copy of the application by going to File > Database > New Copy > Design and Documents, and then deleting all but a few documents. When I copy documents in this way, the views display correctly, but the database size is huge, which makes me think that the original documents have not really been deleted. For privacy reasons, all deleted documents need to be unrecoverable.
My question: How can I purge documents that have been marked for deletion in this way?
While in the database, choose File - Application - Properties from the menu, click the last tab (the propeller-hat) and deselect these two database properties if they are selected:
"Don't overwrite free space" - Obviously you want to overwrite the free space.
"Allow Soft Deletions" - Deselecting this will purge any documents that are deleted but recoverable.
Once you've done that, choose File - Replication - Options for this Application..., click the "Other" tab, and change the date/time to the current date/time. This gets rid of the "deletion stubs" which remain for a time so that, if replication occurs with a different machine, that machine learns that the document was deleted rather than telling yours "Oh! Here's a brand new document!" This is completely unnecessary unless you want to ensure that even the count or internal ids of deleted documents are removed. The actual content will be gone.
After that, compact the database because you'll have free space or, if you want to be really paranoid, create a copy of your copy.
It's been a long time since I did any Lotus Notes development, but you can compact the database.
Open a database.
Choose File - Database - Properties.
Click the Info tab.
Click % used.
If the percentage of a database in use drops below 90% (it contains more than 10% unused space), click Compact to compact the database.
I have a series of about 30 Excel reports (.xlsm), which each have a unique connection configured to a database. The connection is just a short SQL script which grabs the data to be shown on the report. The data is populated into a table (not a pivot table).
Every week we need to update these reports, so I use a simple PowerShell script to open each of the files and refresh the connection.
Every so often we need to send the base 30 reports to other work groups so they can manually update the files on their own. This can be a nuisance because some of the reports are very large (30mb+). This makes emailing difficult, and uploading them/downloading them several times a day is just a hassle.
To mitigate this, before we distribute the report templates I try to delete all the rows in the tables, and any unused range. This has helped, but there's still several files that are VERY large (30mb+) even though we've deleted everything in the workbook except the connection, and the empty table.
Through tests, I've realized that if I delete the configured connection, the file size becomes sufficiently small (<1mb) which is what I would expect. This leads me to believe that Excel connections have a sort of cache that needs to be cleared, however I can't find any references for this.
Does anyone know a simple way for reducing the size of a connection in such a way that I could do so programmatically using VBA/Powershell?
If deleting the configured connection reduces your file size enough, you could write a macro to delete your connections and another to reestablish them. As Noldor130884 suggested, you can automatically execute the macros on Workbook_Open and Workbook_Close.
Office Online - Create, Edit & Manage connections to external data
The above reference seems to make the relevant statement below:
"Removing a connection only removes the connection and does not remove any object or data from the workbook."
It looks to me as if the problem is with the formatting. I don't know why but in my files excel reformatted all rows and columns while adding form with data from connection. Thus the sheet was very large but if you check the xml file it shows only formatting data.. Once I deleted manually all "empty" rows the size of the file is normal again. Hope that helps, helped in my case..
I logged the following question in server fault, and it was suggested I log a dev question related to that question, so here it is.
I have a Lotus Domino DB being archived using the LS method CopyToDatabase. I am about to implement DAOS on the database and need to ensure that attachments are preseved when copied to the archive.
The person who answered the first question suggested that this would not work and that I would lose the attachments. Can anyone advise how to code the archiving (I can only think of using CopyToDatabase) to ensure that the attachment is not lost?
I had assumed Domino would:
move the attachment data from DOAS into Domino when the CopyToDatabase was run.
then move the attachment data back into DOAS if the DB it is copied to also has DAOS enabled.
Thanks,
A
It really is an admin question, but the reasoning does involve understanding things from a developer's perspective, so it's pretty reasonable to ask here.
DAOS is 100% invisible to Notes code at all levels. It doesn't matter whether it is LotusScript, Java, or the Notes C API. The code is 100% unaware of DAOS. You actually cannot write special code that deals directly with DAOS objects.
So, your assumption is basically correct. You just didn't mention the actual part where the attachment is deleted, and a couple of other miscellaneous details.
I.e., if the archive database that you are copying to exists on the same server as the source database, and both are enabled for DAOS, then the attachment will remain in DAOS even after you delete it from the source database.
But if the archive database that you are copying to is on a different server, or if it is on a users's local hard drive, and if the attachment does not also exist in some other DAOS-enabled database on the server, then the attachment will be removed from DAOS. This will occur at the next DAOS purge after the time that you delete the document (or just the attachment) from the source database.
I am attempting to add a document storage module to our AR software.
I will be prompting the user to attach a doc/image to thier account. I will then put a copy of this file into our folder so that we can reference it without having to rely on them keeping the file in its original place. This system is not using a database but instead its using multiple flat files.
I am looking for guidance on how to handle these files once they have attached them to our system.
How should I store these attached files?
I was thinking I could copy the file over to a sub directory then renaming it to a auto-generated number so that we do not have duplicates. The bad thing about this, is the contents of the folder can get rather large.
Anyone have a better way? Should I create directories and store them...?
This system is not using a database but instead its using multiple flat files.
This sounds like a multi-user system. How are you handing concurrent access issues? Your answer to that will greatly influence anything we tell you here.
Since you aren't doing anything special with your other files to handle concurrent access, what I would do is add a new folder under your main data folder specifically for document storage, and write your user files there. Additionally, you need to worry about name collisions. To handle that, I'd name each file there with by appending the date and username to the original file name and taking the md5 or sha1 hash of that string. Then add a file to your other data files to map the hash values to original file names for users.
Given your constraints (and assuming a limited number of total users) I'd also be inclined to go with a "documents" folder -- plus a subfolder for each user. Each file name should include the date to prevent collisions. Over time, you'll have to deal with getting rid of old or outdated files either administratively or with a UI for users. Consider setting a maximum number of files or maximum byte count for each user. You'll also want to handle the files of departed users.
If you have a site which sends out emails to the customer, and you want to save a copy of the mail, what is an effective strategy?
If you save it to a table in your database (e.g. create a table called Mail), it gets very large very quickly.
Some strategies I've seen are:
Save it to the file system
Run a scheduled task to clear old entries from the database - but then you wind up not having a copy;
Create a separate table for each time frame (one each year, or one each month)
What strategies have you used?
I don't agree that gmail is an effective backup for business data.
Why trust your business information to a provider who makes no guarantees of service, or over who you have no control whatsoever?
Makes no sense to me.
Depending on how frequently you need to access this information, I'd say go with the filesystem or database archive. At least that way, you have control over your own data.
Data you want to save is saved in a database. The only exception that is justified is large binary data (images, videos). Who cares how large the table gets? If the mails are automated and template-based, you just have to save the variable parts anyway. The size will be about the same wherever you save it, but you probably already have a mechanism to backup your database, so you won't have to invent one to handle millions of files.
Lots of assumptions:
1. You're running windows / would like an archive in windows
2. The ability to search in the mails is important.
Since you are sending mails to your customers there isn't any reason you can't bcc a mail account of your own. Assuming you have a suitable account on your own server then I'd look at using MailStore (home) to pull the mails out from your account and put them into it's own compressed database.
Another option (depending on the email content) is to not save the email, but make sure you can recreate the email by archiving the original content that went into generating the email.
It depends on the content of your email. If it contains large images. I would plump for the file system. Otherwise if your Mail table table is getting very large very quickly I would go for the separate table, archiving off dead customers.
We save the email to a database table. It really doesn't get that big that quickly. We've a table with 32,000 emails in it (they're biggish emails too # 50kb per email) and with compression, the file only uses 16MB.
If you're sending a shed load of email, then know that GMail(free) currently only allows 7GB of data. I'd be happy holding that on a disk.
I'd think about putting in place some sort of general archiving functionality. How you implement that depends on your specific retrieval needs.
For example if you wish just to retrieve emails sent to a particular customer for a certain month then stocking them in an appropriate heirachy on the File System (zip them up if necessary) should be simple to do. You might want to record a list of sent emails in a database table with a pointer to the appropriate directory but a naming convention for your directories and files might be sufficient
You might not need to access very old emails very infrequently so you might archive these to DVD for example if online storage is a problem
If you're wanting to often search the actual content of emails then your going to have to put the content in a DB table or use an indexer like Lucerne to examine the files stocked on disk