« Domino DST for Dummies - Custom Application Edition | Main| Make Attractive Exports of Categorized Notes Views »

My Domino DST Fix Utility for Custom Applications

QuickImage Category   


As we approach the March 11th start of Daylight Saving Time here in North America, hopefully most folks out there in DominoWorld have completed all the various OS patching, calendar cleanups, Blackberry updates, and what-not.  If you have not, you are hereby granted formal permission to panic.

All joking aside, there is still time to prevent complete chaos from breaking out next Monday, but partial chaos is still a good bet.  If you do NOTHING else, at least get all your servers and workstation operating system patches installed.  If you have a little time left over after that, and you use Domino Web Access for mail, take care of the DWA fixes that involve forms6.nsf/forms7.nsf, etc. If you do not do at least this much, it won't just be *future* times that get set incorrectly starting next week, but *current* times as well (e.g. document creation and modified times, various time stamp fields, etc.).  If you don't know what I'm talking about take a look at the links in my previous post.

A few weeks ago I wrote about how to determine if your DST problem extended to your custom Notes/Domino applications.  Today I wanted to share a few tips and some sample code I used to fix several custom-built room reservation databases.  Note that these reservation databases bear no resemblence to those shipped by Lotus and for which IBM has provided cleanup agents.  That was the bad news.  The good news was that the documents were fairly simple in structure, and that structure was identical across all instances of this database type (each division had their own instance).  I can't show you the actual reservation database design, but all you really need to identify are the affected date/time fields on the documents.

I've created a little database that serves as a central point of reference for identifying affected documents in all your affected applications, and running a cleanup agent to correct the times as appropriate.  This control database is designed to include person documents storing user names and the date/time that user received the workstation DST patch.  This information is in turn used by the cleanup agent to determine whether a given document was created before or after the user's workstation was patched.  If before, fix the time on the document. If after, leave it alone.

To use the database and the included cleanup scripts, here are the basic steps:

Step 1: Copy the following design elements from the control database to each of the affected application databases

- View: DST Cleanup
- View: DST Fix Report
- Agent: (DST - Adjust for New Daylight Saving Time) - Includes detailed code comments pointing out where customization is necessary
- Agent: (DST - Clear DST Fix Flag)

Note: You will of course need to customize and TEST TEST TEST these before they will work for your particular application.  Also, be sure to look at the documents themselves to determine which fields need to be fixed, and not just the form, as sometimes fields are added to the document by form events like the querysave.
 
Step 2: Configure the control database to point to all your affected application databases.

The outline shown here is designed to link from the control database and show the DST Cleanup view inside its own content frame (no need to open the target database directly).

A picture named M2

Modify and add outline entries in the "Main" outline to reflect the server and pathname of each target database, using the syntax shown here:

A picture named M2

Step 3: Populate all the Person documents in the control database and set the DST Patch Dates.

However you do it, the end result needs to be a series of documents, one for each of your users, with the date (and time if available) of when they received the DST patch on their workstation.  The form contains a Division field which might be useful but is not key to the functioning of the cleanup agent.

A picture named M3

If you use SMS or some other method to push out the workstation OS patch, you probably have a record of when each user received the patch and can import a spreadsheet containing that information.  The control database also includes a view action allowing you to set the date on multiple person documents.  Click "Actions - Set DST Patch Date" from the view, as shown here:

A picture named M4

Enter a *valid* date-time and hit "OK"

A picture named M5

Step 4: Review the contents of the "DST Cleanup" views, and run the "Cleanup" action on selected documents.

Again, you MUST customize both the views and the agents provided here to your SPECIFIC situation.  They are not universal agents but provided simply as examples.  DO NOT RUN THESE AGENTS ON PRODUCTION DATA BEFORE TESTING ON A COPY OF THE TARGET DATABASE!!!


A picture named M6

Step 5: The "DST Fix Report" View can be used to provide a printable report to your application owners detailing what your agent just did.  

You'll have to open these views directly from the target database unless you create outline links for them as shown in Step 2.

Download the database here

Your Host

KevinPettitt.jpg
Kevin Pettitt View Kevin Pettitt's profile on LinkedIn

Tools I Use

Idea Jam

Subscribe to This Blog

 Full Posts  Comments

MyYahoo
netvibes Add to Netvibes

Contact

Hosted by

OpenNTF

Disclaimer

This site is in no way affiliated, endorsed, sanctioned, supported, nor blessed by Lotus Software nor IBM Corporation, nor any of my past or future clients (although they are welcome to do so). The opinions, theories, facts, etc. presented here are my own and in no way represent any official pronouncement by me on behalf of any other entity.

© 2005-2017 Kevin Pettitt - all rights reserved as listed below.

Creative Commons License
Unless otherwise labeled by its originating author, the content found on this site is made available under the terms of an Attribution / NonCommercial / ShareAlike