I've got a navigation problem on a notes database. Basically we need one window open per client record so when users open up other items of data relating to the client instead of a new window being opened it needs to close the current window and open the new one in its place.
We then need to store the unique ID and the database of the previous record so that when the user closes the record they are on it navigates back to the previous record.
We have got this working but have to use the "ws.editdocument" command quite a lot and this seems to be causing some major performance problems. We've run it using the debug facility on the notes client and have found that it is actually the EditDocument command that is taking the time and uses nearly twice as many RPC's as opening the equivalent document from a view.
Have you got any suggestions on how to get round using "Editdocument" in this context?
The only thing that comes to mind quickly would be to use an @Command([OpenView].... to crank open the new document. Since it actually performs the functionality of opening a view, traversing it to the correct document and then opening the document, it should have the same performance specs as doing it by hand would. If you have a hidden view that sorts on the UNID, you might be able to shave even more time off the search when you return to the calling document.
I don't know why you're having so much cost in time when using EditDocument, unless Notes is cleaning up memory space for the new document. You could try setting the old document's objects (the NotesDocument or NotesUIDocument) to Nothing before initiating the new EditDocument command, so it would flush the buffers for the existing document first - it may not seem to take as long, as an alternative.
This was first published in April 2002