Working with remote or "occasionally connected" users requires you to write your applications and perform your administration differently than in a LAN-locked environment. Remote users are generally more support-intensive and configuration dependent than your always connected server users and one of the more vexing problems that administrators can have is in deploying Notes applications into the field.

It's a fairly common practice to send buttons that perform various administrative functions to your users via a Notes email message. The one button that I've seen mailed most frequently adds Notes databases to a user's workspace and creates any required environment variables. These buttons are, of course, real times savers, and most of us have one or more of these in our toolkit. For this month, we're going to combine those functions with local replication and then perform the steps necessary to cascade the database in the local user's NOTES.INI file.

Back to the example
For the purposes of our example, let's go back to last month's example and assume that the database we want to deploy locally to our users is located on the Dallas/Fort Worth server "DFW001" and is called "APPS\ROLODX.NSF". Using the configuration items described in last month's article you (or your developers) should have created a database that contains the views and fields required to work as an address book. The coders, testers, and beta users of the application all feel like proud, happy parents and management is ready to see this thing in production.

How do you get this creation out into the field? Create a button with the logic shown in the attached listing, change the name of the server and the database where indicated in the source code, then mail it off to all the users of the application.

Walking through the code
Let's look through the code, available at http://www.component-net.com/dp-extras/ini1198.html, and see what we've got to do.

The code in the listing should be placed in the Click event of a normal LotusScript button. The first things that you should put at the top of the script are the application specific variables. That way, when you use this button again (you do want to re-use code as much as possible right?), all that you'll have to do is change the header section and the rest of the logic can remain unchanged. Lines 3 through 5 perform the setting of these variables. Next, lines 8 Ð 12 perform the normal LotusScript setup processing for our script.