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.
Related
Question #1: is it possible to restore deleted items from backup in Sanity.io?
To my understanding, restoring a backup is done by exporting all documents from a dataset's history, and importing it.
Restore - there's one way to do it: https://www.sanity.io/docs/importing-data.
Export - there're two ways to export data:
Export all currently-existing-data: https://www.sanity.io/docs/export.
Export one historical document by its ID: https://www.sanity.io/docs/history-api.
IDs of deleted items do not appear in currently-existing-data (because they are deleted, duh), and without them, I can't get historical documents.
Also, there's a Gotcha section saying:
Gotcha
Current Access Control means if you're able to access the document today, you'll be able to access all the previous revisions of the document.
Question #2: if restoring deleted items from backup is NOT possible due to those missing document IDs - is there a way to automatically save all document IDs (either every hour or whenever a change occurs)?
I guess that if there's a mechanism that also saves the last time an ID was seen, you can also know more or less its deletion time...
I saw that the Sanity.io project has a webhook that gets triggered when changes occur (under 'Settings' tab --> 'API' sub-tab).
I guess this could be set to call a service that gets all documents and save their ID with the current timestamp.
Whenever I restore an AS Database, the DB files are created in a new folder by name DBName_[1-n] wherethe number is incremented by 1 after every restore. I am currently looking for a script to copy the files[or this ASDBName_[n]] dynamically to another server.
Is there a way to find the file path of the ASDatabase through DMVs/ AMO or any other manner?
Regards,
Sasi.
The numbering is used by AS to handle transactions: Each write operation creates a new copy with a new number, while the old version can still be used for read access. If, finally, the write operation - be it a restore or a processing or a structural change - succeeds, AS switches all users to the new version, and can then delete the old version in the background. If anything goes wrong during the write operation, the new version can just be deleted by AS without affecting anybody using the previous version. This can happen on database level, and as well at sub-object level (if you e. g. process only a dimension, or add a measure to a measure group).
This also means that in order to be sure you copy the database, you have to detach it - which makes sure that it is in a consistent state, and not a half written rest stays around. Then you could copy it to a new server, and attach it there. And, as long as the database is detached, there should be only one version, so you could just take the one and only folder of name "DBName.<n>.db".
I do not think there is a documented possibility to find the exact name. At least, Microsoft does not document one at http://technet.microsoft.com/en-us/library/cc280670.aspx. They just state "Use any operating system mechanism or your standard method for moving files to move the database folder to the new location."
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
Actually I am in need of counting the visitors count for a particular document.
I can do it by adding a field, and increasing its value.
But the problem is following.,
I have 10 replication copies in different location. It is being replicated by scheduled manner. So replication conflict is happening because of document count is editing the same document in different location.
I would use an external solution for this. Just search for "visitor count" in your favorite search engine and choose a third party tool. You can then display the count on the page if that is important.
If you need to store the value in the database for some reason, perhaps you could store it as a new doc type that gets added each time (and cleaned up later) to avoid the replication issues.
Otherwise if storing it isn't required consider Google Analytics too.
Also I faced this problem. I can not say that it has a easy solution. Document locking is the only solution that i had found. But the visitor's count is not possible.
It is possible, but not by updating the document. Instead have an AJAX call to an agent or form with parameters on the URL identifying the document being read. This call writes a document into a tracking DB with one or two views and then determines from those views how many reads you have had. The number of reads is the return value of the AJAX form.
This can be written in LS, Java or #Formulas. I would try to do it 100% in #Formulas to make it as efficient as possible.
You can also add logic to exclude reads from the same user or same source IP address.
The tracking database then replicates using the same schedule as the other database.
Daily or Hourly agents can run to create summary documents and delete the detail documents so that you do not exceed the limits for #DBLookup.
If you do not need very nearly real time counts (and that is the best you can get with replicated system like this) you could use the web logs that domino generates by finding the reads in the logs and building the counts in a document per server.
/Newbs
Back in the 90s, we had a client that needed to know that each person had read a document without them clicking to sign or anything.
The initial solution was to add each name to a text field on a separate tracking document. This ran into problems when it got over 32k real fast. Then, one of my colleagues realized you could just have it create a document for each user to record that they'd read it.
Heck, you could have one database used to track all reads for all users of all documents, since one user can only open one document at a time -- each time they open a new document, either add that value to a field or create a field named after the document they've read on their own "reader tracker" document.
Or you could make that a mail-in database, so no worries about replication. Each time they open a document for which you want to track reads, it create a tiny document that has only their name and what document they read which gets mailed into the "read counter database". If you don't care who read it, you have an agent that runs on a schedule that updates the count and deletes the mailed-in documents.
There really are a lot of ways to skin this cat.
Me and my colleague are trying to implement a mechanism to get recovery from broken files on an embedded equipment.
This could be happened during certain circumstances, e.g. user takes off the battery during file writing.
Orz, but now we have just one idea:
Create duplicated backup files, and copy them back if dangerous file i/o is not finished properly.
This is kind of stupid, as if the backup files also broken, we are just dead.
Do you have any suggestions or good articles on this?
Thanks in advance.
Read up on database logging and database journal files.
A database (like Oracle) has very, very robust file writing. Do not actually use Oracle. Use their design pattern. The design pattern goes something like this. You can borrow these ideas without actually using the actual product.
Your transaction (i.e., Insert) will fetch the block to be updated. Usually this is in memory cache, if not, it is read from disk to memory cache.
A "before image" (or rollback segment) copy is made of the block you're about to write.
You change the cache copy, write a journal entry, and queue up a DB write.
You commit the change, which makes the cache change visible to other transactions.
At some point, the DB writer will finalize the DB file change.
The journal is a simple circular queue file -- the records are just a history of changes with little structure to them. It can be replicated on multiple devices.
The DB files are more complex structures. They have a "transaction number" -- a simple sequential count of overall transactions. This is encoded in the block (two different ways) as well as written to the control file.
A good DBA assures that the control file is replicated across devices.
When Oracle starts up, it checks the control file(s) to find which one is likely to be correct. Others may be corrupted. Oracle checks the DB files to see which match the control file. It checks the journal to see if transactions need to be applied to get the files up to the correct transaction number.
Of course, if it crashes while writing all of the journal copies, that transaction will be lost -- not much can be done about that. However, if it crashes after the journal entry is written, it will probably recover cleanly with no problems.
If you lose media, and recover a backup, there's a chance that the journal file can be applied to the recovered backup file and bring it up to date. Otherwise, old journal files have to be replayed to get it up to date.
Depends on which OS etc. etc. but in most cases what you can do is copy to a temporary file name and as the last final step rename the files to the correct name.
This means the (WOOPS) Window of Opertunity Of Potential S****p is confined to the interval when the renames take place.
If the OS supports a nice directory structure and you lay out the files intelligently you can further refine this by copying the new files to a temp directory and renaming the directory so the WOOPS becomes the interval between "rename target to save" and "rename temp to target".
This gets even better if the OS supports Soft link directories then you can "ln -s target temp". On most OSes replacing a softlink will be an "atomic" operation which will work or not work without any messy halfway states.
All these options depend on having enough storage to keep a complete old and new copy on the file system.