Skip to main content

Domino transaction method testing update

 2021 is here. I hope this year will be full of better things and our lives will get to normal, where we can travel and meet each other again. For me, it started in quarantine, but all tests were negative. Another change was that I'm HCL Ambassador for the very first time in 2021. I hope it will force me to blog and speak even more about HCL products, especially about all the goodies in V12 and beyond. 

Last year, I've done a few tests of the new transaction methods. HCL checked my issues, so now it was my turn to do a few more tests.

Problem with view access after a document save

In Test 4 of my initial tests, I've found that you can no longer access views after you save a document. The problem seems to be deeper in the Domino code, so for now you must disable autoupdate on the view object. 

This, of course, means that you will not get up-to-date result, because you'll work with the old view index. An interesting fact is, that the view index is not updated even when you directly call refresh() on the view object. No error is thrown, but the results seem to use the old index. 

DQL access

The most important part that I've skipped in my initial tests was DQL. I think we all will use more and more DQL in future Domino apps, so it's important to check the behavior. 

At first, I went for a pure Form = 'Doc' query, which for whatever reason resulted in nsf scan. This worked just fine within the transaction. I wanted to check the interoperability with view indexes, so I've created another view and used 'All'.Form = 'Doc' . This forces Domino to use the view. 

The results of the tests are a bit confusing to me. The default behavior is that the DQL does not refresh the view, which leads to the same result as autoupdate set to false. So you get inconsistent results. What is more interesting is the behavior if you set refresViews to true (I've done it on code just for these queries, but you can enable this globally using QUERY_REFRESH_ALL_VIEWS=1 notes.ini parameter). The result was:

This basically means that the refreshViews had no effect while being in the transaction. I guess the reason will be the same as in the previous paragraph, where the manual refresh call had no effect, but It's up HCL to verify/explain that.

I hope a full beta package of V12, including Designer, will be released soon, so we can test this more easily than having to compile code outside and add it to Domino as a jar.


  1. One correction - autoupdate is unnecessary if you turn on inline updating of the view, which applies updates at NoteUpdate time.



Post a Comment

Popular posts from this blog

Microsoft Word black box in numbering issue

This is awkward post, primarily to save the solution for future me. I have seen many people mentioning this problem over years and as I've struggled with it several times, I needed to find final and permanent solution. All editions of Microsoft Word from time to time suffer from bug in numbering. Instead of a number, black box is displayed. Sometimes it happens right after document is opened, sometimes during editing. Probably some internal structure of document gets corrupted, so based on level of corruption, different fixes could help. Many of them are listed at I took different approach. Since docx is just standard zip package with xml files, I decided to try if I can fix it manually. And it worked. When I extracted the docx, there was file called numbering.xml in word folder. When I examined that file, I found strange se

HCL Domino SSO with Microsoft Teams

 Microsoft Teams is probably one of the most used tools this year, it was already quite popular before the pandemic started to spread across the world this spring, but now most of the businesses I work with use it. After using it just like a chat/conferencing tool, many start to explore further capabilities of the platform. When working with Domino data in apps that are web-enabled, it can be quite easy - just add a web tab anywhere you want. The problem is, that you need to deal with user authentication. 

Quick Tip - SSJS Error line numbers

 Recently, I had to work on an app with a pretty huge server-side JavaScript codebase. Several developers with different levels of XPages knowledge worked on that project in the past, to the code is quite hard to follow. My suggestion to rewrite all the code to Java was not accepted, so we have to deal with SSJS for now. One of the most annoying things, when you work with SSJS, is that in many cases you don't know where an error is happening. If you keep things simple and allow redirection to an error page (default or custom), you get a lot of information, and usually, you don't want to scare users with that or you may even want to do something useful in a catch block to recover from the problem. If the problem is thrown directly in the XPages JS engine, it's usually an InterpretException, which contains the context information, but if you have to deal with standard Java exceptions, you don't have it. Imagine a simple scenario with a function in a ssjs lib. When you run