Best Practice: How to reference another database

To do a lookup or search in another database, you need the filename or the replica id.

ReplicaId vs. filename?

  • With the replica id, you don’t know wich server you end up using. You can provide a hint server – but Notes will often just use the top most bookmark (and this could be the server in singapore)
  • Replica ID’s is hard to maintain. If you have a developer, test and production version af the database – you need 3 different replica id’s.. If you forget to change the replica if when moving to production, user will still use the test database…
  • If you use a filename, then the database must have the same filename on all servers and local replica (or you must maintain a complete list) In real life this is not a big issue, as most databases will be deployed using the AdminP or Policies (and therfor have the same filename)

Based on this, I allways use the extact server+filename of the database

Where to store the information?
The filename of the lookup database, can be stored in a profile document or in some keyword documents in the source database. The approach has some problems:

  • Typically you dont specify a servername – you use db.server or @subset( @dbname; 1 ) to use the current server. This will be correct in most locations – but in some locations you have both a mail server and an application server. In this senario you cant use the current server to make a lookup from a mail file to a project database.
  • Speaking of mail files – you want to make as few design changes a possible to the standard template (so extra profile documents is not pleasent)
  • Maintenaince: Sometimes it can be nessesary to move a lookup database – or to change the design. If the database is moved you have to update the profile documents in all databases. But which database did use this lookup database?

The solution is simple: create a central database where you can registre all your lookup databases. Give every reference document an unique id – and give the central database a fixed filename. You will have to make an extra dblookup by the id to find the actual database – but you will also get:

  • Central maintenaince
  • A great overview of all lookup databases
  • You can easily move or rename the lookup database

I use my own DbConfig database for this. You are welcome to download it and use it – it’s free

In the DbConfig database I have added some extra functionality

  • Every lookup will leave a tracking document. In the usage view, you can see all source databases (So, to answer the question: “Which databases makes use of xxx?” – just look in the usage view)
  • You can create expections, like: on all servers, except MAIL01 you should use the currentserver – from MAIL01 you will find the application on APP01
  • You can make relative references (to find the lookup database relative to the current directory)
  • You can have multiple dbConfig databases on the server. Lookup code will use the nearest (the one in the same directory as the source database. If not found here, it will use the dbconfig in the root…)

6 tanker om "Best Practice: How to reference another database"

  1. Hello, I use the same db as you did. I named it crosser 🙂

    but I decided to use ReplicaId as the way to open database.

    and how do you get the ALIAS to database? in my db I use next approached:
    – i have form with next format -Name- and if I found form with first sumbol – and last sumbol – as well I get it as alias, and in case if there is no such form I use the name of database as alias.

    but definitely the idea good, because now I use my database in every project where more then 1 database.


  2. You give it your own alias, e.g. I call my agent log database for ‘LOG’. To open the log database I use this code in Lotus Script: config.getDatabase( “LOG” ). Very simple…
    Works from formula language as well – check the ‘Developer Sample’ form in the database.

  3. Hi Jakob

    Nice post!

    I must admit that I haven’t seen your DbConfig, but as you I’ve been working like this for many years now.

    I have a comment to this priciple:
    The central Database Config is a good idea – but I also use a “deploy” feature that pushes the database configurations out the the databases that uses them.

    The reason is performance – when the database needs to make the lookup the is performed much faster if the data is gathered from it self.

    If you combine this with a LS Object Cache feature, our database lookups are performed rather quick.

    Best regards,

    Christian Gravgaard,
    Independent member of Notesnet group –

  4. Hi Christian,
    Performance should alwas be considered. In this case I don’t think it is a big issue – I only make one cached lookup in a small static database.
    In this way, my solution is very simple – no deployment, no maintenaince – and the opportunity to have several databases on the same server …

  5. Hi, greetings from New Zealand. I too use a similar configuration database I developed some years ago.

    It too pushes its address(filename) to all databases making the lookup run from the local db.

    I do all lookups by database title and obviously they have to be unique but this makes the code that does the lookup completely portable as it just calls a function GetDatabaseByTitle (db.title)

    Apart from db locations it also stores globally accessed lists within our company.

    I’m using your RSS Reader but it doesn’t seem to handle using a proxy server. Is that correct?

    Best Wishes and thanks for a great site.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *