A customer was having trouble with design elements being changed on their production servers. More times than they could remember, adverse affects were seen from these changes. For example, the company had standards in place to prevent developers from putting time-sensitive formulas like @Now or @Today in views, but there wasn't anything stopping the developer from publishing the database and then changing the view after it was published to use items that didn't meet standards. Breaking Par was approached to see if a solution could be found.

The first suggestion was to not allow Designer or Manager access to any database in production. The drawbacks to doing this proved to be too great, however. At least two applications would have been necessary. The first one would have been an application to maintain Access Control Lists on all the databases on each of the servers. The second one would have been an application to allow developers to enable and disable scheduled agents for each database on each of the servers. With both applications, a background agent with sufficient access would have to run to actually do the processing. This would have meant a lot of agents running on the server and slow (3-4 minute) turnaround between the time of the request and when it was actually processed.

Working with the company's developers (splitting the work to save costs), a good solution was built. The part Breaking Par developed was to, on a nightly basis, populate a database (one database per server) that listed every design element in every database on that server, the time the design element was last modified, and who modified the design element. This was an API program that would run through all the databases on the current server, and for each database run through all the design elements. Each design element would cause a new document to be created in the log database.

The customer's piece involved writing scheduled LotusScript agents to go through the log database and look for design elements modified in the last day. The design elements would be evaluated to see if they came from a database that was put into production in the last day (they already had an application that logged databases being put into production). If the design element didn't come from a database that just went into production, the support team was notified of the source server, source database, the design element, who modified the design element, and when it was modified. The support team would then contact that developer to find the reason for modifying the design element in production.

Not surprisingly, after having this process in place for a couple of months, the number of design elements being changed in production dropped to almost nothing. And the reliability of their production application servers was increased because only designs that met standards were on the servers.