I was recently tasked with modifying a Lotus Notes application in my workplace.
Before starting I created a new replica of the live program into my PC drive using Replication > New Replica option.
After I modified it and entered some dummy data, I went back to check on the live program. Only to notice that not only did my dummy data appeared in the live server, but also the form design that I modified replaced the live design (luckily I just added some fields, so its no big issue).
Naturally I deleted the dummy data from the live version view. And when I come back to my test version, when I try to delete the exact same dummy data, I get an error saying
Document locking is enabled. You must lock the document before deleting.
So I did that, which gives me another error saying that document has already been deleted. Meaning that although my original form data was deleted, the view data still remains in limbo. I can open it and see the form's content, but I cannot edit it anymore.
I was lucky that I deleted the dummy data through the live version, but now I want to delete the same data from test version.
Is there anything I can do to fix this?
Important note: If you need a test database which is completely separate to any live database, don't create the test database as a "new replica". Create it as a "new copy" instead (in the Notes client, use File -> Application -> New Copy).
Making your local database as a new replica means that it replicates changes between the local file and whatever server you replicated it from.
Most likely, your Notes client had been previously configured with scheduled replication enabled, so any changes (in either design or data) made in either the local database or server database are automatically replicated to the other. I can't tell you how often it replicates, since that's a configurable option, but it's probably once every few minutes.
In the case of your "already deleted" document, the deletion in the live database would have been replicated to the local database. To make the document disappear locally, simply close and reopen the database (but if prompted to delete documents currently marked for deletion, choose No).
Edit...
Another thing to try to make the local document disappear is manual replication. You can get a list of local database replicas via what the Notes calls the "Open List". This appears by default as an "Open" button immediately below the File menu, or its contents may appear in a vertical bar down the left side of the Notes window if you've ever chosen to dock the Open List.
In the Open List, click the "Replication and Sync" option. Its icon is two curved arrows that almost form a circle.
"Replication and Sync" lists all databases for which you have local replicas. To immediately replicate just one database, find that database title, right-click it, and click "Replicate Selected Application".
If the database is currently open in Notes when replicating, you may also need to manually refresh the view to make deleted documents disappear (the F5 and F9 keys should both refresh the current view, but you only need to press one of them).
Related
I have a notes database and recently we are having an issue across random documents. Users gets error "The linked document cannot be found in the view" when they try to open a document from a view. I am not sure how to reproduce this issue.
I tried the below options to reproduce it, but no luck:
Attaching a document link to one of the Rich text field and deleting the link's target.
Attaching a file as a link and deleting the file in the target.
I am not seeing any pattern with the documents having the issue. The documents accessed few days ago, which was not accessed for more than 2 years also becomes corrupt like this.
Other details:
The Field info tab in Document properties dialog box is empty
There is no scheduled agent running overnight affecting this documents
No change was done to the database recently
We recently migrated to Notes 11.0 from 9.0
Since we have a daily backup of the database, we restore the document from one of the restored copy in which it was working fine.
A guess: did you try re-indexing the view? Shift-F9?
It could also be in the form, or even the view.
What if ...
you open the same document from a different view?
you remove some, many or all fields from the form, do you still see the error?
I think those documents have actually been deleted, and two things make me think that:
You say in a comment that rebuilding the view makes the documents disappear. I'd expect this only if the documents no longer exist.
I have in the past had LotusScript code doing view lookups which produced documents that I knew to be deleted, but the NotesDocument.IsDeleted property was False and the NotesDocument.Items property was Empty (i.e. no fields in the document). This is consistent with your saying the Field info tab is empty.
I'd check if any user action or code could delete documents. You say there are no scheduled agents, but maybe some user action could run code which deletes documents, or some users with the Delete privilege in the database ACL could be directly deleting documents using the Delete key on the keyboard.
Also check the database properties -> Info tab -> User Detail. This should show if there are recent deletions, but the record is probably limited to the last week or less.
We have a view which gives users an ability to work with documents where we made our own logic for copying documents. It is accessed with a special button on the view. But the standard behavior of copy paste key shortcuts is still there and some users are using it instead and this is breaking some of our logic.
Is there any way to prevent users to copy \ paste documents within Lotus database or at least a certain view?
Yes. If the user don't have author/editor/depositor access they can't paste documents into the database.
You also have the QueryPaste event in the view, you can use that to prevent documents from being pasted in.
In Notes 8.0.2 you also got a new database property (under the advanced tab) called "disable export of view data". You can use that one as well.
There is also a 'disable copy' system field you can apply to any document. If the document contains a field called $KeepPrivate with a value of "1" then document copying is prevented in the client UI. It prevents copying to the clipboard and printing out. It doesn't prevent screen-print of course. It doesn't prevent pasting in either (see paste agents to control that). Readers cannot paste in a document or edit existing data too. You can set/clear $KeepPrivate as needed and $Readers too if necessary.
I have a strange problem: I want to access documents in a different database (same server). My approach is very close to this one discussed here: http://www-10.lotus.com/ldd/nd85forum.nsf/DateAllFlatWeb/517ef6249d5b9fa6852575cc00503786?OpenDocument
I have only 3 docs in the source database. 2 are created directly, one is copied from another database (these are just test document). We have a generic view that lists thos entries from a view, calcs the links in a form like this:
http://localhost/database.nsf/xpMBK.xsp?action=openDocument&db=dominotest%2Ftest%2Fulcbs%21%21projects%2FFKIE%2FEinsMuB.nsf&view=AMBKEinsAll&documentId=781F14A98A699548C1257C3200316BAC
As you can see we are using an Xpage in the current database and place parameters that point the Xpage to open the document to the source database (notation is server!!database here), a view (this is the one to which I want to return) and finally the unid of the source document.
Now the strange one:
I cannot open the copied document, receiving the
NotesException: Invalid universal id
lotus.domino.local.Database.getDocumentByUNID(Unknown Source)
error.
Even better: if I copy a document that works within the same database (the current one) this document can also not opened anymore!
What's this and can you give me a hint to solve this?
Thanks in advance!
If, by "copied", you mean either manually copied and pasted into the target database or programmatically duplicated via copyToDatabase(), the new copy of the document will be assigned a new UNID; it is not guaranteed to have the same UNID as the original did (and, in my experience, it's rare that it preserves the original). If you're duplicating the document programmatically, be sure to check its new UNID afterward and use that ID in your URL calculation instead.
I've had a problem very similar to this in the past, and the answer turned out to be that I wasn't opening the NSF file that I thought I was opening. I was using NotesDatabase.OpenByReplicaID, and there were two replicas of the database on the server, with different sets of documents. In that situation, Notes gets to pick one of the two replicas -- you have no control over it. The replica that was actually opening contained some of documents corresponding the the UNIDs that I was trying to access, but some of them really were not there and therefore the getDocumentByUNID() method was correct in throwing the "Invalid universal id" error. This was really, really hard to debug.
After I figured it out and removed the second replica from my server, the first thing I did (after testing and confirming the problem went away) was to write an agent that scans a server for duplicate replica IDs.
The UNID:S in a Domino database when it's copied to the database thru copyToDatabase is done like this.
One part of the UNID comes from the database one part is document unique. So if you copy a document from one database to another the document could get the same unid each time. If the unique combination doesn't have a valid document with that combination in the database, the document will get the same UNID everytime. In other cases the document will get a new Id.
More information can be found here
UNID and copytodatabase
Thank you guys for your ideas!
But I was completely wrong #facepalm
The problem was: a colleague coded a bean to access the other database and I didn't noticed that the config document pointed to a replica on another server, so when I copied the document within my database on my local server it was fairly clear that the xpage could not find the copied one - as it resided on the other machine.
Thank you anyway :)
I have an embedded view in a main form (same database) with a single category of a client code that is custom generated. The view displays all other documents that have that main document's client code in a hidden field.
This works perfectly, except for one user where the embedded view is blank, and the message "category not found" is displayed. This happens for all documents viewed. Anyone else that opens the exact same main documents can see the correct list in the embedded view. The documents are definitely there.
I've pressed F9 a few times, and the "category not found" keeps coming up. I've also shutdown Notes and deleted the cache file, and restarted. There have been no changes to the database for a long time, and this started for this one user a few days ago.
I have no idea whats causing this.
Check readers/authors fields in documents that should be displayed in your embedded view. May be that user just can't see them.
Before I get too stressed, I generally try this:
Remove the database from the user's workspace
Compact the workspace (2nd tab of workspace properties)
Close Notes
Delete cache.ndk
Restart Notes
If that doesn't work, I'd check that the user can see the documents in another way (i.e. if you send a doclink to the user, can the user open it (alternatively, try opening the embedded view directly through View - Goto. Don't forget to use CTRL-SHIFT at the same time if the view is hidden)? If not, the user may have lost a role, or dropped out of a group that provides access.
¿The view is "shared" and not "shared, private at first view"? In that case, you have to delete de "private version" of the view for that user
¿The embedded view is calculated, and show one view for a group of users and a second view for another group? Maybe you're searching the problem in the wrong view
¿The single category is based on a formula or on a calculated field? In that case, the formula calculates a different value for that user
I copy pasted some document from production server db to Dev server db , but when I tried to open any of these document then its giving error like ...The server with this database is no longer responding , should notes switch to a replica or another server ...whether old documents are opening fine in the Dev database.
Any suggestion appreciable...
Thank you.
The answer is going to be in the design of your application. You'll have to figure this one out on your own.
For example:
Does this record have computed or static fields (or formulas) pointing to the production server?
Does the form for the record use the 'unid' in one of the calculated fields (possibly as a key)? If so, you will get a broken key following the paste, since the last saved unid value would no longer match the actual doc unid.
Does your record have any other dependency records, that you also need to copy over?
Does your record have references (such as #DbLookups) to missing configuration records in your dev system (such as "keyword" lists or "system documents/profiles")?
Good luck