Andrew Pollack's Blog

Technology, Family, Entertainment, Politics, and Random Noise

Setting / Changing the UNID on documents - a fantastic hack for fixing problems or creating development copies of databases

By Andrew Pollack on 07/05/2008 at 12:11 PM EDT

Credit where it's due, Nathan brought this one to my attention. He's using the technique for something else he'll be blogging about later with a great deal of excitement. When he told me what he was doing, I wasn't as interested in how he was using it as he was (have to keep that part a secret) but I was pretty interested in the little hack he's taking advantage of.

You can set the Universal ID on a Notes Document. I wasn't aware of this, but in lotusscript, NotesDocument.UniversalID is not a read-only property. You can set it. You need to be extremely careful with this, as you can really screw things up. That said, there are a few good uses. Here are two of mine:

1. Have you ever had to re-create a document that was deleted but due to the replica ID being different it messed up your response hierarchy or lookups, or whatever? Just set the UniversalID to the one the old document had (you can get it from the $REF field on a child document, for example) and your child documents or lookups, or web url's all work.

2. For making a non-replica copy of a database to do design work on, create the copy of the database with "Design Only". Once done, create a quick agent to copy all the documents from the original to the new copy, re-assigning their Universal ID in the process. This gives you a very nice non-replica to work with.

Here's a script I used:


	Dim session As New notessession
	Dim thisdb As notesdatabase, otherdb As NotesDatabase
	Set thisdb= session.CurrentDatabase
	Set otherdb = New notesdatabase(thisdb.Server,"otherdb.nsf")
	Dim col As notesdocumentcollection
	Dim newdoc As notesdocument, olddoc As notesdocument
	Set col = otherdb.AllDocuments
	If Not col.count = 0 Then Set olddoc = col.GetFirstDocument
	While Not olddoc Is Nothing
		If olddoc.IsValid Then
			Set newdoc =New notesdocument(thisdb)
			newdoc.UniversalID = olddoc.UniversalID
			Call olddoc.CopyAllItems(newdoc)
			Call newdoc.Save(False, False, False)
		End If
		Set olddoc=col.getnextdocument(olddoc)
	Wend


Some things to note about using this technique:

First: If you take an existing document, change its UNID and save it, you're creating a new copy of the document. The old one is still there. You'll have to delete the duplicate. For a workaround to this, create a new document that hasn't been saved yet, copy the unid from the original onto the new document, then use originalDoc.copyAllItems(newdoc) and finally save the new doc. This will prevent duplication.

Second: If you try to re-use the same UNID that exists already, you'll get an error on the save. Two docs in the same database can't have the same UNID and you'll get an error.

Third: If you use this technique and make two docs with the same UNID in different replica copies of the database, you'll get replication conflicts when they meet.

There are other concerns, but you'll have to bug Nathan to post his blog entry about what he's doing since I'd be giving things away if I went down that road.


There are  - loading -  comments....

re: Setting / Changing the UNID on documents - a fantastic hack for fixing problems or creating development copies of databasesBy Bob Balaban on 07/05/2008 at 01:31 PM EDT
You can also change the UNID of a document to modify the creation date. I've
done this in C before, don't really know how easy/impossible it might be in LS
Another way to do this without codeBy Jamie Magee on 07/05/2008 at 05:57 PM EDT
NoteMan Toolbar (http://www.NoteMan.com) lets you ad hoc change the UNID of any
doc in two clicks (but not yet in batch). An upcoming version lets you opt to
"preserve UNIDs" when copying a selection or collection of docs to another db,
including more than Notes' limit of 2335 docs.

Another way to make a non-replica copy with preserved UNIDs is to make a
replica of the db, then with a couple clicks of NoteMan Toolbar change the
ReplicaID. Now you have a full non-replica copy with all the original UNIDs
(and signatures!) intact.
re: Setting / Changing the UNID on documents - a fantastic hack for fixing problems or creating development copies of databasesBy Kevin Pettitt on 07/05/2008 at 11:27 PM EDT
Ytria's ScanEZ has both the change ReplicaID and Change UNID function, and also
preserves UNIDs (it doesn't ask though) when doing a batch copy of documents
between databases. I don't know what the document limit might be, if any.

I've also recently found some API Lotusscript code over on the Breaking Par
site for changing Replica IDs. So that might be an option too:
http://www.breakingpar.com/bkp/home.nsf/0/87256B280015193F87256FF200556ED1
re: Setting / Changing the UNID on documents - a fantastic hack for fixing problems or creating development copies of databasesBy Matt White on 07/06/2008 at 05:06 AM EDT
Although you can certainly do this, I'm not sure that I'd recommend it unless
you really know what you're doing and there is absolutely no other way of
working around the issue. I've seen it used a couple of times by people who
maybe didn't fully understand the implications of what they were doing and it
caused really serious problems with the application replication.

But I agree it is very cool to use when you need to.

Matt
Also used in the personal Calendar to "Import Holidays"By Kevin Pettitt on 07/06/2008 at 03:18 PM EDT
I discovered that the Import Holiday agent used this technique of forcing a
specific UNID on a specific holiday when a the agent failed for user on a
specific holiday. Turns out the part of the agent that clears out the previous
entries missed one because that document had lost some of the field items that
allow the agent to find it. So everything blew up when it started repopulating
and got a unid conflict.

Once I figured out which holiday it was, I could create a view to select for
just that UNID, and the stray doc popped up.

Lesson there was to trap for that error (4091) and then go grab the existing
document with that unid, kill it, and then pick up from there.

In the meantime I've already put Nathan's upcoming trick into a client
application (I got a sneak peak too), and it works great. :-)
re: Setting / Changing the UNID on documents - a fantastic hack for fixing problems or creating development copies of databasesBy John Marshall on 07/11/2008 at 08:54 AM EDT
This code does not take into account response documents. If you change the
parent UNID the child document will no longer be associated with its parent.
Some simple recursive code to find the and update the response documents with
the parent UNID is needed to tackle this issue.
You are absolutely mistaken.By Andrew Pollack on 07/11/2008 at 09:42 AM EDT
This code will copy all documents, parent and child. The child will have a
$REF field on it that contains the UNID of the parent. When the code runs,
both the child and parent will retain their original UNID in the new database,
and thus the $REF field will properly reference the parent.

On top of that, I've tested this code and it worked perfectly with a full
response tree.
re: You are absolutely mistaken.By John Marshall on 07/11/2008 at 10:46 AM EDT
My bad, didnt read it properly as usual sorry. Your not changing the guid so
I'm an idiot.
re: You are absolutely mistaken.By John Marshall on 07/11/2008 at 10:48 AM EDT
I normally create an a Simple agent and use "Copy To Database" to keep guids
the same.


Other Recent Stories...

  1. 11/10/2014Simplified explanation and steps for upgrading to SHA-2 encrypted SSL certificates for DominoI went through the process to understand what IBM is saying in their patch information -- and while it's valid, it's also harder than it needs to be (IMCO) for people already used to doing things the Domino way. If you're already familiar with using the server certification database to create the keyring and make the certificate request certificate (CSR) you can keep using it. This is also helpful if you already have a SHA1 based certificate and you just want to re-issue. Note: This resolves the browser ...... 
  2. 11/04/2014Warning: IBMs Interim Fix¬†adding TLS 1.0 to Domino can break connections from Python and some other scripting clientsHere's a bit of joy to add to your day. Once your server can speak TLS 1.0 to help secure you from POODLE attacks, any code making connections to your server over HTTPS that use the utilities wget, curl and most importanly Python (and others, apparently) may break. The issue is that these tools are built using a version of openSSL that will try to connect using TLS 1.2 first -- and when that fails, the connection gets dropped. I've seen reports of this in Ruby as well, but I've verified that it is an issue ...... 
  3. 11/04/2014Patch for the SSL v3 POODLE exploit has escaped IBM and can now be downloaded. You REALLY need this patchIf you do not apply this patch, you are going to start having users unable to connect using SSL to your Domino servers. Vendors and customer sites are starting to release operating system and browser patch that block access to sites using only SSLv3 without TLS. Until this morning, that meant all Domino servers not using a reverse proxy front end of some kind. This patch adds TLS 1.0 to Domino versions 8.51, 8.52, 8.53, 9.0, and 9.01 in all the various platforms. TLS 1.0 is a fairly old version of TLS but ...... 
  4. 10/29/2014Automatic Spam Report to Provider Agent 
  5. 10/21/2014Quick update on the Domino SSL v3 "POODLE" , TLS, and SHA-2 issues -- Good news 
  6. 10/16/2014Summary Recommendation for dealing with the POODLE SSLv3 Vulnerability on Domino servers 
  7. 10/14/2014Speaking tonight ath the ICU One (aka NE Notes Users Group) 
  8. 10/09/2014Presentations from AdminCamp 2014 
  9. 09/17/2014IBM Domino Servers STILL don't support SSL SHA-2 Certificates - and it is about to be a PROBLEM 
  10. 02/09/2014Changing what I do at the Fire Department 
Click here for more articles.....


pen icon Comment Entry
Subject
Your Name
Homepage
*Your Email
* Your email address is required, but not displayed.
 
Your thoughts....
 
Remember Me  

Please wait while your document is saved.