Hi there,
I would like to have a link from one form (form A) to another form (Form B). I have a radio button “YES OR NO” asking the user if “FORM B” was created. If FORM B was created, i would like to have a link to that specific form. Is this possible? In form A I have a field that may relate to a field in form B. Form A - field is called “cycle” and in form B - field is called “cycle1”, however, both fields in each form will always match … Any ideas? Thanks!
Subject: Creating a link from one form to another
It sounds like you would want to have a button visible only if your radio “Yes/No” field evaluates to “not Yes”. If the “not Yes” condition is met, the button would be visible and the next consideration would be: Do you only want the ability to create a new document, doc b, linked back to the origin doc a, or do you want to establish a criteria to list existing doc b’s that are eligible to be linked back to the original doc a, or both? It sounds like you just want the ability to link a new doc b to doc a, which is simple. Set it up so that doc b will be using a response form. In a computed-when-composed field on the response form, use @InheritedDocumentUniqueID as your formula. When saved, this will translate into a doclink back to doc a, or the main, parent document. Make sure that your response form is set to inherit values from the selected document.
Subject: RE: Creating a link from one form to another
Hi there,
Actually, I have two forms, FORM A and FORM B. FORM A will ask the user if FORM B was created. If FORM B was created, I would like a link to open FORM B. Not quite sure how to link the two if FORM B was created. In form A, I have a text field called cycle and In form B, I have a text field called cycle1 but both should be equivalent to one another. Also, Form A - I have another dialog field called Env and in Form B - called Env1. These fields should be the same in both forms, I’m not sure how to link the two forms together. Thanks!
Subject: RE: Creating a link from one form to another
Hey Claire, What you must keep in mind is that these are documents that you are seeking to link, not forms. The forms are the underlying framework that host the UI documents. If for example you take the names of all of your fields, create a new form in designer and duplicate those field names, and assign to the “Form” field of the document the name of the new form, or use a form formula in a view action to use the new form to display the document, your data will render via the new form, as a document. When a user creates and fills out the information in a form and saves it, the information is saved as a document. When a user opens the document, the document uses the form as a template to provide the structure for displaying the data.
So really what you have is DOCUMENT A asking the user if DOCUMENT B was created…in order to have been created, it must be a document.
First, how are you creating document b? For your purposes, you should be creating document b as a response document, with the form properties set as I mentioned in the previous post, “Formulas inherit values from selected document”, checked. This is located within the form properties box, on the defaults tab, in the On Create section.
Second, what do the fields that you have mentioned have to do with it? Okay, so both of the fields that you have mentioned should have equivalent data values in both documents, is that the criteria for the documents being linked? Are you seeking to link documents based upon field data values, or upon a parent/child relationship?
Subject: RE: Creating a link from one form to another
Hey Andrew,
Thanks for your help, I really appreciate it. I’m actually a new developer using designer so I guess my “lingo” isn’t proper. I do apologize. Anyway, I was hoping to link Document B to Document A based upon field data values. Should my text/dialog box fields be the same name in order for this to work? Again, thanks!
Subject: RE: Creating a link from one form to another
Hi Claire, That’s okay no need to apologize that’s what this forum is all about…a place for developers new to the notes platform to learn more and for those with some experience to share their knowledge freely.
Okay so we are working with existing documents. Do you know if the documents “a” are main documents and documents “b” are response documents, or vice versa?
We should determine that first and take if from there. Create a view…with a selection formula of SELECT @All. I am going off the notion that we are only working with two distinct documents hence two separate forms. The first column should be ascending/categorized…and its formula will be the word Form, with no quotation marks. This will group all of the document a and document b documents by the form which is their underlying structure. Make sure that the view property “Show response documents in heirarchy” is deselected. Create a second column, and plug this formula into it: @If(@IsResponseDoc;“Response”;“Main”).
Let me know the results. If we are working with all main documents, we will need to create an agent that will examine the criteria you specified with the field values, and write the document UniveralID’s to each other for reference when found. However if we are working with a combination of main(doc a) and response(doc b) documents, we can use a special field in the response document called “$REF” to perform the linking.
Subject: RE: Creating a link from one form to another
Andrew is working on the assumption that one of the documents is a response document – I’m betting that is not the case.
You don’t have to ask the user whether there’s a corresponding document that uses the other form. You can determine that yourself.
There’s no way to just associate the fields on the different forms. You will have to use @DbLookup to find out whether a matching value exists. So let’s say that you have a view of FormB documents, sorted by the field cycle1. In FormA, you might have a hidden computed-for-display field (FormB_ID) that determines whether there’s a FormB document with a cycle1 field that matches your cycle. The formula for this field might be:
@Text(@IfError(@DbLookup(“”:“NoCache”; “”; “FormBDocumentsSortedByCycle”; cycle; 1; [ReturnDocumentUniqueID]); “”))
Now you can use the field in a hide-when formula for a button. The hide formula might be:
FormB_ID = “”
And the button can use the following LotusScript code:
Sub Click(…)
Dim wksp As New NotesUIWorkspace
Dim uidoc As NotesUIDocument
Dim doc As NotesDocument
Dim strID as String
Dim docB as NotesDocument
Set uidoc = wksp.CurrentDocument
Set doc = uidoc.Document
strID = doc.FormB_ID(0)
On Error Goto Nevermind
Set docB = doc.ParentDatabase.GetDocumentByUNID(strID)
wksp.EditDocument False, docB
Exit Sub
Nevermind:
Messagebox "Couldn’t open FormB document with key " & doc.cycle(0) & “!”, 0, “Open FormB”
Exit Sub
Subject: RE: Creating a link from one form to another
Not automatically working off of the assumption of existing response documents…but exploring that possibility to determine the best approach…as per my suggestion to display forms used and form types via sorted columns/column formulas. If nothing else that also helps a beginning notes developer to get a better handle on a database they might be assuming responsibility for. Unnecessary, perhaps, but if I am being given the task of modifying and maintaining a production database I did not create and has been live for a period, I always deploy a hidden view as described so I know exactly how the existing data is structured. If in the event there are indeed response documents involved I can simply use the $Ref field to link to parent documents. Andre your suggestion is def. good and will certainly work efficiently…however I have an existing engineering application(713) which I created two years ago. This leads to my question for you: One of the primary necessities of this database at the outset of development was the ability to create associations with existing documents in another database(ECR). The necessity of association(in this context, by association I mean the ability of the two documents not only to include the ability to provide links to one another, but to know one another’s status based upon a check I built into each form’s querysave event), is determined by a field for part numbers that the documents in the two databases both contain. By clicking on a “create association” button in either document, I can quickly populate an array consisting of documents that contain the same part number in the ECR database as those in the current 713 document, or vise-versa, and display the contents of the array via the prompt method of the uiworkspace class for selection. I am storing the result(the univeral ID’s of the selected documents from the prompt) in a multi value field, which will then allow the user to access them from a button that retrieves the associations from the multi-value field…and the querysave event will also update them when, e.g., the document status is set to closed. This is bi-directional and can be a one to many association either way. Given this scenario, even without the one-to-many ability, my question is this: Wouldn’t it be more efficient, if I was inheriting this application and the associations were non-existent but required, to create agents to construct the initial framework, to do the work of finding all documents in the ECR or 713 databases whose part number value contains a match for the part number of the ECR or 713 document being processed, and adding those documents’ univeralID’s to the multi-value field where they will be reliably stored for permanent, instant access and underlying operations such as status updates…rather than performing a dblookup every time I want to view document associations? Of course you need to add some code to the querydocumentdelete method of the database script to update relative documents upon deletion, but wouldn’t the performance gain and the simplified ability to perform field updates between the documents, etc. be worth it? I know that the formula language is a greater performer than lotusscript, however wouldn’t it be advantageous to run the updating agents once rather than performing dblookups continuously? I have wanted to ask this question for awhile the context of your response finally motivated me. Within the same thought…I developed the aforemention application entirely upon the framework I described…I am not using ANY dblookups. All lookups are performed upon the multi-value fields mentioned, which are otherwise inaccessible to the end user. There is obviously a maintenance downside via possible document deletion, but that is easily handled in the dbscript. I have no need in this database for a dynamic lookup every time an association is created, moreso, every time an association listing is requested…they are static and handled internally. I know that notes conventional wisdom is to use @dblookups or @dbcolumns regardless as they minimize erroneous results…but wouldn’t you agree that there are instances, such as this one, where use of those @functions are actually hindering functionality? There is no REAL association created between the documents at document or field level. And the idea of using the parent-response capabilities is not an efficient solution when you are spanning databases…I have found working @dblookups to sometimes fail when moving databases to new servers even though you think you have addressed that possibility by using “” for the server:database arguments or @DbName etc…It seems to me that this approach is the way to make notes databases semi-relational…truly associated and even programmatically aware of one another’s activity. Just some ideas was curious about your take on it. TIA for any feedback.
Subject: RE: Creating a link from one form to another
While @DbLookup is certainly slower then accessing pre-existing data in the document, it’s basically foolproof – the data displayed are guaranteed to be up to date as of the moment the document is opened.
While there may be performance issues that can justify keeping copies of information, you pay for improved performance in decreased reliability, greatly increased complexity of your code, and information that less current. The programming task of keeping all the data consistent is non-trivial, especially if there are multiple replicas of the application.
Let’s take a simple example. FormA contains a list of “links” to FormB documents that have a matching key. This list is updated by an agent whenever a FormB document is added, updated or deleted (the update might involve changing the key value in FormB, so it should attach to a different FormA document).
That seems simple enough. But let’s suppose someone has a local replica of the application. They create a FormB document in their local replica. Later they open the FormA document with the same key. The link to their new document is missing. The agent runs on a server, and while they might have replicated their change to the server, they haven’t yet received the updated FormA document from the server.
Now let’s say someone in the server replica deletes a FormB document. Now there is an invalid link in a FormA document. How does the server agent know that a document has been deleted? There’s no “when documents deleted” trigger to run an agent. You would have to do something to make sure that every time a document was deleted, some code of yours would run to do an update. This involves either a really slow agent that checks all FormA documents to see whether the documents they refer to still exist, or writing DSAPI code – a possibility though not one that most Domino developers would savor – or some event being triggered by the user’s workstation immediately either just before or just after the document is deleted. Unfortunately, Domino doesn’t use a two-phase commit process. There’s every chance that an inconsistency will be caused by a failure in the code between the time one change is committed and the second change is attempted. The network connection could be lost just after saving or deleting the FormB document and before the FormA document can be updated. The user could press Ctrl+Break. The save to the FormA document could fail because of a save conflict. Worse, the save could succeed because you are overriding save conflicts, and someone else’s change could be overwritten.
Or, of course, if the application is on multiple servers (and/or local replicas) – inevitable for high-availability applications – do all servers update the documents, or only one of them? If all (which would include the case where related documents are updated immediately in form events), what’s to prevent replication conflicts when users on two different servers add FormB documents that contain the same key? If only one, there’s a double replication delay before links on other servers are up to date. What happens if that server is down? Does everyone have to wait for the server to come up before their links are up to date?
Plus, there are performance and other drawbacks to updating documents every time a related document changes. Changing documents unnecessarily causes additional churn in view indexes, increased replication times, loss of unread marks, and agents triggering unnecessarily on “modified” documents whose modifications are unimportant to the agent. The chance of save conflicts rises greatly – what happens if you’re editing a FormA document while someone else creates a FormB document with that same key?
If you do opt for having the related document updated automatically with code run on the user’s workstation, you either have to run it under the user’s ID (which means you have to allow all these users who can create/modify FormB documents access to edit all FormA documents) or you have to use RunOnServer, which is a bit more complicated and is also a bigger burden on the server, and which only works if there’s a server available (i.e. not in a disconnected local replica).
That’s why, when I recommend to someone how to create relationships between documents based on a key, storing link information in the documents is not the first thing that occurs to me to suggest. I’m not saying I wouldn’t do it that way ever, but not without a very good reason or special circumstances that make it easier to control for the above factors (e.g. the application is only accessed thru a web browser from one server, or performance is a serious problem and I’ve run out of other ways to address it).
Another way to accomplish this functionality that Claire might consider, is the use of an embedded single-category view (which might be in a section – that lets the user choose whether they want to wait for the update by opening the section). Or, she could use a live lookup that only is performed when the user presses a button – until then, they don’t know whether there are any related documents.
Subject: RE: Creating a link from one form to another
Yes there are undoubtedlly many considerations and potential drawbacks to the design that I applied to the previously mentioned application. It is a very small and distinct set of circumstances that will allow such an approach to operate efficiently on a consistent basis. Definitely an ad hoc technique. For my purpose, it is neither strictly accessed via the web and performance is def. not an issue(just thought of mentioning it as a possible), but it does reside on a single server, moreover, it is not used offline and replicated under any conditions and it is a distinct group of engineers using it. Yes, the code is definitely more complex than dblookups, but to achieve the same functionality using that approach would have required: a. the use of document values, or keys, rather than universal ID’s, (if I am not storing the document ID’s of related documents within a multi-value field, how else would I have been able to identify related docs so effectively), b. we know that data is only as reliable as the diligence of the end user(s) to use and maintain it properly…if I am performing my associations on anything other than the stored values of the multi-valued fields of document ID’s, a margin of error is created in assuming that simply because part numbers match in two documents that the end user has actually created the relation…if the association is created “under the hood” by the application, then dblookups will work, however in this case it is up to the engineer to use a button which lists the available “form B’s” in either database which meet the previously described criteria and upon selection from that list create the association(storing the selected documents universal ID sequentially into the hidden multi-value field). Unfortunately not all seemingly viable documents are eligible for association, some parts are slated for obsolescence…really, that is one of the driving factors behind the chosen approach. Off the top of my head these items were the primary reason to go this route. Summarily I am happy to say it has worked beautifully, live for over two years now without a single instance of support. I accredit that as much to the greatness of the notes platform as I do the development technique. I must say that I love knowing that these documents are truly related and dependant on one another. The proven efficiency of the application has shown me that I can make notes jump through hoops to the extent that documents can be truly relational without the main/response technique. I admit I was prepared for some extended support, though :). I was def. not going to suggest this approach to Claire. I was actually thinking at the outset of, yes, running an agent to scan existing documents for field matches as per the criteria she outlined and create links between the documents based upon universal ID’s but only to bring existing documents to a functional state…beyond that something along the lines of the approach you explained in your initial response. However I think the idea that you mentioned of a single category embedded view hits the nail on the head. The single category would operate off of a view whose first sorted column contains the categorized listing of the formB documents by the “cycle1” field value, while her formA “cycle” field value is the formula for the single category displayed. Theoretically this sounds flawless. Claire, are you still with us? My apologies about the details that we started discussing that went beyond your initial question…Andre is a developer of the actual product who is good enough to peruse this forum on a daily basis offering solid solutions and advice…I have been meaning to talk to him for awhile about this very subject and this thread presented an ideal forum for it. That said, thanks for the detailed response Andre.
I have another topic that I have wanted to discuss with you for awhile relating to integrated back-end data stores accessed via ASP/ADO.NET vs. Lotus Notes/Domino 7. We know they are apples and oranges but as we progress towards more web-based applications there are some capabilities in the ASP/ADO.NET platform which immediately generate a wish list for ibm/lotus developers.
Subject: RE: Creating a link from one form to another
Are you thinking in terms of integration with .NET or more flexible access to federated data in ND7?
(Proposion’s N2N is a good solution for the former.)
Subject: RE: Creating a link from one form to another
The latter…thanks for the response I met the developer of Proposion a couple of years ago at Lotusphere(simple enough he was running his own booth). Def. a solid product. An ado.net control for domino objects…that is cool.
Subject: RE: Creating a link from one form to another
Andrew is the winner of the prizes for longest sentences and longest, scariest-looking paragraphs. 
Perhaps you would be so kind as to shift this discussion to the beta feedback forum and propose your feature ideas there – I would be most happy to hear them, but unlike my answering questions here, IBM actually pays me to read the beta forum, and evaluating feature suggestions is part of my job.
Subject: RE: Creating a link from one form to another
LOL!
No problem Andre I’ll post there later on…thanks.
Subject: RE: Creating a link from one form to another
Hi guys,
Thanks so much for your help. I’ve been a bit busy to check the status of responses for my original question. I will definitely advise you of the outcome. Once again, Thanks!
Subject: Creating a link from one form to another
Based on this brief description (you provide no details about the document contents and how they’re “related”), one likely answer is to use noteview.getdocumentbykey against a view that sorted by the desired field value to find DocumentB, and then notesuiworkspace.editdocument to open it. And you don’t have to ask the user if DocumentB exists, you can see if your getdocumentbykey returns anything or not. You can even run the getdocumentbykey from queryopen (in an existing document, not a new one) and set the value of a flag field to control whether the link is visible, making it appear ionly when there is a DocumentB.