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…)