In 1735, Benjamin Franklin wrote an anonymous letter to his own newspaper, the The Pennsylvania Gazette, on the subject of how to prevent fires in people’s homes or, as he put it, “the different Accidents and Carelessnesses by which Houses were set on fire, with Cautions against them, and Means proposed of avoiding them.“
In the letter, Franklin wrote the now famous words, “an Ounce of Prevention is worth a Pound of Cure.“ He goes on to warn that “Scraps of Fire may fall into Chinks, and make no Appearance till Midnight; when your Stairs being in Flames, you may be forced, (as I once was) to leap out of your Windows, and hazard your Necks to avoid being over-roasted.“
These days, most of us buy into the concept of preventive care. We show up at the doctor's office for our annual physical, or at the dentist to have our teeth cleaned and inspected. We take our cars in for service. We have our home heating and cooling systems checked, cleaned and serviced each year. We don't typically wait until we get sick, a toothache, our car breaks down at the side of the road, or the heating system fails in the middle of a snowstorm.
What about our software applications though? How much time and effort do we spend in taking precautions to avoid potential problems before they happen? There are many things that can go wrong in a software application, especially an HCL Domino app that may have been doing faithful service for decades in some cases, since it was originally created as a Lotus Notes application.
Here at Teamstudio, we've built a few different analytical tools over the years that go looking for problems before they happen. But we have never found the same level of commitment to preventive measures in the software world as we do in our private lives. Take Teamstudio Validator as an example. It's our second least popular tool. And yet it has the potential to save hundreds of hours and thousands of dollars in wasted time and effort.
HCL Domino, or Lotus Notes, as many still refer to it, is nothing if not controversial. Many love it, some hate it, which may have something to do with its quirkiness. The non-relational, hierarchical structure of the NSF database format is fantastic for representing certain types of information, but can have some weird side effects. Orphaned documents, for example, which are documents whose parent has been deleted and which therefore may never show up in a view, but just might show up in a search.
Combine that with the fact that many Domino databases are getting a little, ahem, mature, and you can understand why this platform is uniquely positioned to present some challenging data integrity problems. Which is why we developed Validator. An incredibly powerful tool that can search through your elderly Domino databases looking for problems before they happen. For example:
Broken doclinks
Doclinks are a great way to navigate around Domino apps - just like hyperlinks on the web. But just like hyperlinks, they don't work if the target document or database has been moved or deleted. And you'll only find that out when a user clicks on the broken link.
Save/replication conflicts
This is where two different copies of the same document have been updated either simultaneously or between replication events. In our experience, this problem is most often resolved in practice by randomly deleting one of the conflicting copies!
Failing validation code
Validator will check default value, input translation and validation code to make sure there is nothing preventing that code from running. For example, the code could include an @DbLookup call to a database or view that no longer exists.
Field inconsistencies
Fields that are no longer required may have been deleted from all forms, meaning that they just take up space in the database and are never used. Or the other way around. Worse, field types may have changed, for example a field that was stored as text may correspond to a field on a form of type number.
Keyword fields with incorrect values
This is where the value of a field in the document does not match one of the keywords as defined in the database design.
Missing design dependencies
In this example, an actual design element that is needed to display or execute code on a form is missing. It could be a missing subform or shared field, for instance.
Orphaned agent data notes
This test scans a database to identify agent data notes that are no longer being referenced by an agent. Agent data notes are design elements created and used by agents when they run. Over time, some databases accumulate hundreds of these elements, increasing the size of the database. Since most orphaned agent data notes are no longer attached to an agent, they will never be deleted. There is no easy way to remove them since they do not show up in Domino Designer.
In short, Validator gives you an easy way to spot potential problems in your older Domino applications before a user comes across them. So why would anyone not want to get out ahead of those potential problems and fix them before they show up? Maybe it's because someone else suffers the pain when things go wrong. If I don't get my teeth checked twice a year, it's me that will have to suffer the pain and inconvenience of a root canal down the road. But if I ignore the integrity of my aging Domino apps, then it's only some poor user who will suffer later.
If that sounds like you (or let's say someone you know), then you just might want to take a look at what Validator could do for you and your users. You’d make Benjamin Franklin proud!
To learn more about Teamstudio Validator, click below. If you’d like to see what it can do for you, you can request a free trial.