I don't do that any more. I now use @Unique. There are several reasons why I have switched. There is no doubt that getting a document by UNID is quicker than opening a view then getDocumentbyKey but I really don't think the price is particularly high.

Reasons Not to use the UNID:

1. If you ever have a save/rep conflict you may destroy the relationship depending on how you resolve the conflict. But then I know you never get any save/rep conflicts :-)

2. When working with a new document and you get the UNID it will be different after the document has been saved. Where I ran into this is a situation where I created a related document from while a document was still new and cost me a lot of time trying to fix it.

Now I just have a field on the form I called it LinkKey (customcontrol) that defaults to @Unique() and go from there. In one case I needed to create 'response to response' documents in the third level down I store both the the Key back to the top level Parent (ie grandParent) as well as the key to the Parent. So I can go back and forth from the child to the parent to the grandparent or from the child directly to the grandParent. I control all the lookup by some very simple views that contain only the LinkKey sorted. I have not tried this in very large DBs, but it works really well in repeat controls where I getAllDocumentsByKey(LinkKey) and feed that into the repeat control. The beauty of this is that you can spread the cost of the lookup over time so that each lookup might be slightly longer that a get by UNID but it is probably never noticeable to the end user.

I have been using this method in native Notes applications (with single category views) as well as in XPages  and repeat controls. Love the repeat control because you have so much more control.

Bill

Rod,

I NEVER EVER use response documents in XPages.  I would avoid that at all costs?  Why?  We'll there's just so little need for them since there are other ways to relate documents and in XPages you might want to have related documents live in different .NSF files.  I do that a lot.  So response documents would only limit you if you need to spread out to multiple .NSF's.

I do as Bill does.  I use @Unique keys for almost everything.  My reasons for preferring that over the UNID is simply that I've just always used @Unique - even back in the client world.  I just never got into using UNID's that much.  I think it's because I like to have test databases and if I copy documents from production and paste into my test db I want to make sure they work.  Since since the UNID can change in that situation that would stop me from refreshing a test database.

Keep in mind that @Unique() in XPages does NOT give you the traditional format of the Notes Client.  If you want that, which I prefer, you need to do a session - evaluate.  That can work in SSJS and Java.

Definately don't try to reproduce the TableWalker stuff.  Use related documents and repeat controls.  Use related documents like you suggest.

I did a NotesIn9 on this concept a while back.  I've probably done it on a couple shows but this MIGHT be similar to that you're trying to achieve.  http://notesin9.com/index.php/2010/05/12/notes-in-9-018-xpages-data-relationships/

Good Luck!!

Dave

I have never used @Unique in that way! In fact, I didn't even know it did that! Wow, how did I ever miss that?

I have used @DocumentUniqueID and stored it in a field and passed it to my "response" documents but I always ran into the problem that I had to save the primary "document" first before I could create the secondary document or "response".

I guess no one out there is going to champion the "documents" and "responses" method for XPages!