Thursday, February 16, 2006

Show-n-Tell Thursday


Taking up the call to arms, here's my tip. Not as impressive as many, and quite a hack to boot, but it solved a problem we had.

Issue: our field users' mail files were getting huge, and needed to be compacted on a regular basis. But many of them didn't even realize they had a server replica; all their work is done locally, with replication settings that are just a magic button to them. Asking them to open their server replica to compact it would cause major panic. I don't know why there wasn't a server task in place to handle this; I'm not an admin. In any case, there's a lovely Compact method available in the NotesDatabase class, but it only works on local replicas. So how do we get these users to manually compact a server-based replica they're not even aware of?

Solution:

1. Put an action button in my Inbox (or any other view/folder) with this code:

server := @Name([CN]; @Subset(@DbName; 1));
serverFile:="mail\\" + @Subset(@DbName; -1);

@If(
server!=""; @Command([FileDatabaseCompact]);
@Do(
@Environment("CompactNow"; "true");
@Command([FileOpenDatabase]; "yourServer" : serverFile ; "($Inbox)"; "" ; "1" ; "1" )
)
)

This first tests to see if the database is local or server; if it's server it does the compact; if it's local it sets an environment variable and opens the server database. Again, I'd need to add a few lines of code to determine the correct mail server for each user (just a dblookup to their local names.nsf to get their location document, I think.)


2. In the Database Script PostOpen event, I put the following code:

x:=@Environment("CompactNow");
server:=@Subset(@DbName; 1);

@If(server!="";

@If(x="true";
@Do(@Command([FileDatabaseCompact]);
@Command([FileCloseWindow]));
""
);
"")

Every time the mail database opens, it tests to see if it's server or local. If it's local it does nothing. If it's server, it checks to see if the environment variable that was set by the button is equal to "true". If it is, it runs the compact and immediately closes the database. If it's not "true", it does nothing (just leaves the database open for people who normally work in-office with server replicas.)


3. In the Database Script QueryClose event, I put the following code:

@Environment("CompactNow"; "")

This ensures that the variable is cleared out when the script from PostOpen closes the database so that the next time the user opens it, it doesn't automatically compact.

At least in my tests, all of this happens so quickly that you don't actually see the server replica open at all. It will take a few minutes for the Percent Used number on the server replica to adjust, but this is the case even when you run compact manually using the Compact button on the database properties box.


Show-n-tell Thursday

2 comments:

Anonymous said...

There is a server task. It's called "compact" (of all things!). The usual practice is to set up a program document that invokes it on a schedule (e.g., after hours, on weekends, etc.) and passes various arguments that determine what databases it will compact, how much free space to leave, etc.

Esther said...

Thanks, Rich. Bad phrasing on my part. I'm aware of the server compact task; what I don't know is why it wasn't working correctly/set up correctly/providing the results the admins wanted.