Share a LotusScript library between databases

Question

Is it possible to create a LotusScript library in one database and then access it from another database?

Without simply copying the library into each database that needs to use it.

What I would like to achieve is a single location where I can update the library and not have to manually copy it over to each database that is using it. I can't use a design template as the databases that use this script library all use different design templates.

I guess another solution would be to create an agent to copy the library out to all databases whenever it is updated. So if anyone has done anything like that before then I would also like to here about it.

Answer 1

Design inheritance in Lotus Notes isn't only on database level - individual design elements (such as your script library) can be explicitly inherited from a different template. See Linking individual design elements to a template.

With inheritance set up like this, the designer task on the Domino server will update the design element automatically. For this to work, the templates must be replicated to the same server.

You might want to disable this inheritance when you release your template, to avoid nasty surprises in the production environment. I created a solution for this a while ago: Remove Lotus Notes design element inheritance programatically.

Answer 2

Anders has answered the question very well. As Anders has already said, Domino, unfortunately, cannot share code libraries between databases. All the code is self contained, which is in this scenario a limitation.

Copying the agent into all the databases you want to use it for, and then employing design inheritance is a quick and easy way to distribute the agent.

An alternative idea, is to have a single database that serves as a repository of agents, so if you need to re-use the same agent over and over, it's design is always in one database, but you will need to design it so that it can perform operations on all the database you need to update.

Effectively, using each database as a datasource only, and the relevant agent(s) operating from one location. It will require some more work that will allow you to define some additional configuration documents that the agent(s) would use to identify which databases you want the agent to run on.

The advantages of this approach are :

• You don't need to contend with design inheritance. It can get messy on a large scale when you have complex script library/design structures, you may have to buy third party tools to help you do this.

• You can actually control which databases get updated via a series of configuration documents centrally with an "active/inactive" field that flags the database for update. Rather than directly "touching" the agents which requires you to get your hands dirty with enabling/disabling the agent. In some corporate environments which are tightly controlled, you need to keep asking the Notes admin to do this for you.

• You can code the agent so that it reports activity in your own custom log documents when it runs on each database, and centrally store it.

Hope this provides you with some options...