Do you ever have applications that need to work in multiple environments? You know what I mean: Maybe you have separate Development and Production environments. Or, Development, Test, and Production.

Or, maybe, like us, you're a consultant and have your own internal environment plus the client's Development, Test, and Production environments.

If you have this situation (doesn't pretty much everybody?), you should write your applications to be able to work seamlessly when moved from one environment to the next.

Generally, that's pretty easy to do, but what do you do if you have to do lookups to outside reference databases? If you can be absolutely sure they are always in the same path with the same file name, you can hard-code the lookups, but that always makes me a little queasy.

Alternatively, you could make a keyword document which holds the path or replica id of the database being looked up but, as soon as you do that you've suddenly required double the lookups: one to look up the replica ID and the second to do the lookup to the database.

Not ideal, either.

A approach we often use in situations like this is to put a Computed For Display field on the form and compute out the correct replica ID to use for the lookup database based on the current server. Then, all your lookup formulas simply use the value in the field as the replica ID they're looking up to.

The code is simple and straightforward and saves a lot of time messing around as you move versions of the database from one environment to another:

Teamwork := "85256BD8:0057E563";
ClientDev := "852568CC:00523B4B";
ClientTest := "85256ADC:004B56D5";
ClientProduction := "852569CF:007CBB56";
REM;
Domain := @Domain;
REM;
@If(Domain = "AcmeTest"; ClientDev; Domain = "AcmeQA"; ClientTest; Domain = "Acme"; ClientProduction; Teamwork)

Like I said, simple and straightforward. Remember, though, not to do this with a Computed or Computed When Composed field. If you do, the value will be stored in the documents, which can cause you problems down the road.

1. Chad Schelfhout03/02/2006 01:14:15 PM
Homepage: http://www.chadsmiley.com

I remember doing that same thing, but now I use an alias and lookup the database or other information in documents. This allows me to make one change without having to re-compile, and it can be used in LotusScript, Java and Formula

Here is a better description and of it: http://www.chadsmiley.com/ReferenceLookup.

2. Andrew Brew03/15/2006 12:12:29 AM

I never much liked using replica Ids for lookups, because:
1) If there is a second replica on the right server (a restored copy or the like) it will break
2) If there is an icon pointer on users' workspaces to a server that no longer exists (more common that you might think) it will break
3) Even if you have control of the server environment, and are careful to avoid 1 and 2, it is hard-coding to a particular environment (in this case, environments, but it is still hard-coding), and when the environment changes, it will break

Having said all that, yes, it does save you a lookup (once per session, not once per document - naturally such lookup results would be cached). If you do find this technique useful, I would suggest using server:path pairs instead:
Teamwork := "Server1" : "dev\testlookupdb.nsf";
ClientDev := "Server2" : "dev\testlookupdb.nsf";
ClientTest := "Server3" : "lookupdb.nsf";
...etc.
This avoids problems 1 and 2, at least.

3. Scott Good03/15/2006 07:40:44 AM
Homepage: http://www.scottgood.com

Hi Andrew,

Everything you've said is true and your suggestion will work great. Where you're reluctant to use replica ids, I'm reluctant to use file paths. It seems more likely to me that servers will be reorganized and file paths adjusted than that databases' replica ids will be changed. Using replica ids, while the things you've pointed out are true, completely gets you around the problem of "where is the database and what is it called?"

As to avoiding the lookup, while that's not a terribly big deal if you (a) cache it and (b) do the lookup in a single field that's referenced by anything else in the form needing the replica id (or path), what makes me a little unhappy about keeping this information in lookup documents is (a) you have to either update the information every time you move the database between servers or make individual lookup documents for each environment, and (b) it's one more thing you have to remember to include in your database before it will work.

In any case, your way works as well as mine. Po-tay-toe or po-TAH-toe? Take your pick.

Scott

4. Bernard Horowitz08/07/2007 07:10:16 PM

Forgive me if I am wrong, but as an administrator I have always been taught that hard coding servers, paths etc was the wrong thing to do. I was always taught that the best practice is to code via RepID (servers change, paths change, but rep ID's stay the same unless you have a real good reason to change it).

I am in a discussion with my developers right now who are using letter combinations (like IS) to help lookup a path. They have some system that it goes to the first match of IS instead of a rep ID. With the onset of the ISPY database this screws them up and they want me to rename the databaes title so they can continue to code in the same manner. This seems really odd to me and against everything I have learned. What gives? Am I just old school and a hardass or are they doing this a bit whack?

5. Scott Good08/08/2007 08:55:04 AM
Homepage: http://www.scottgood.com

Bernard,

I'm just as old school about hard-coding server names and paths. Replica IDs are the best way to go, with a couple of possible exceptions.

The first is if you are referencing the current database. In that case, you can skip identifying the server : path/Replica ID altogether and insure you'll always find the right database even if it is someday copied and/or moved. This is a case where adding a replica ID actually makes the application slightly more likely to break.

The other place where I use paths is in situations where the file path is highly dependable. For instance, while it is possible to have address books with other file names, Names.NSF is pretty darned universal in Notes and I'd rather have a lookup pointed at that than at the Replica ID.

Similarly, we have a client that has two databases which contain, respectively, person and location information (address, various roles at each site, etc.). These databases were created to eliminate the need for all their application databases to duplicate more or less the same information for looking up workflow roles and the like. The client has a rule (which they also follow) that these two databases will be on EVERY server and will always have EXACTLY the same paths.

This is another place where we hard-code the path into lookups. Because of the absolute consistency of naming, this actually makes it easier to move from Development to Testing and then on to Production as these lookups don't ever have to change. So, this is a good place to use hard-coded names but it is also highly unusual.

The short version of this long answer (the exceptions noted above notwithstanding) is: I don't like to use paths in lookups. Keep pushing for replica IDs. That approach is a lot easier to get (and keep) right.

Scott