DesignBais Tip – Housekeeping

DesignBais requires very little maintenance but here are a couple pointers.

The DBIXMLLOG file tends to get very large if logging is turned on, and periodically needs to be cleared. Logging is enabled on a per-user basis from the Users maintenance form. In each DesignBais-enabled account, Clear-File on this file at some periodic interval, perhaps with a phantom scheduled to wake up once per day when there are no users. Another way to quickly clear the log for the "current" account is to use the Clear XML Log button in the Actve Users form.

The DBISESSIONS file in pre-v4 releases also accumulates data and can be cleared when there is no user activity. Do not clear this file if there is any chance that a user will want to resume a login session afterward. That is, you must really be sure no one is even sitting on a page waiting to continue data entry. One way to clear the file is to go to the Active Users form and click Clear Sessions. This eliminates most but not all items in the file. A clear-file as part of the periodic housekeeping process will keep the file clean.

For D3 sites (and other DBMS platforms that use mv.NET in v4 or above), mv.NET creates temporary files which also need to be cleaned up occasionally. These files are named MVNET.TMP_x where x is a number starting with ‘1’. Periodically execute this command at TCL: MVNET.HOUSEKEEPALL You are prompted to do a complete housekeep or to just delete temp files. Enter ‘FILES’ to just delete the temp files. The verb and response can also be added to the periodic housekeeping phantom or similar application process. mv.NET includes excellent housekeeping routines of its own, but these are only invoked when using a pooled connection that is always logged-in. DesignBais manages its own pooling of Dedicated Connections through non-pooled mv.NET sessions. So, without its own dedicated connection, mv.NET doesn’t know when it can or should handle its own housekeeping, so this needs to be done manually.

DesignBais v4 has enhancements which may eliminate a couple of these housekeeping issues. I’ll update this article in a few weeks and ensure that the v3 and v4 differences are clear.

Menus allow a program to be execute from this field: "Subroutine to invoke before screen". See the DesignBais Manual for details. This is a good place to put common routines that clear up your own work files. Be careful to not "weigh down" the user interface though – you don’t want any one user to wait to get to a form while the server is busy trying to delete some massive file that isn’t properly sized. It may be best for the program specified in this field to check to see if there is a housekeeping phantom running, and if not, spawn the process, but major housekeeping should not be done by user processes. See the other related field for Menus, "Subroutine on Main form Close (‘X’ button)" — you can be fairly certain a number of your users will just kill forms to exit them, rather than using a Close button. Don’t rely on this code getting executed however – users often find creative ways to exit applications without the server knowing they’re gone.

One type of housekeeping function is making sure that your users are still active and not consuming licenses while they’re "out to lunch". One way to monitor user activity is to use the DBTIMER feature:

• In your AFTER DISPLAY event, save the current date and time (perhaps form name or other data) in a DBSTORE or DBWORK value.
• When users enter your event handlers, update this timestamp so you know the last time the user had some "real activity".
• In your AFTER DISPLAY event, check to see if there is a timestamp already in place. If not, use DBTIMER=30000 or some similar value to set the timer. The DBTIMER uses AFTER DISPLAY as its event, so if there is already a timestamp, then the form has fired off this timing event.
• Check the current time with the last timestamp. If some significant amount of time has gone by without any activity then the user may have gone away for a while. You can popup a form (with its own timer) to give the user the opportunity to confirm they’re actually still at the keyboard. If the user doesn’t respond you can close their appliction form, redirect them to a login page via PROCESS.STACK, perform some wrapup housekeeping, and take other actions.
• Of course more infrastructures is required around this to ensure that you don’t terminate a user session prematurely. For example, they might simply be working on another screen, and you don’t want to close pages on them or interrupt their other work. In this case, DBSTORE is inadequate and you may need to read/write your own user state data whenever the user fires certain types of events. Put some thought into it and consider exactly how you expect users will be using the software. No doubt you’ll be surprised by how they are actually using it.

If you have your own housekeeping tips to keep the DesignBais runtime or development environment "clean", please post a comment!

The article GUI for MV Developers turned out to be much larger than I expected. It will take another week to cut it back a little. Please come back next week for that article.

I have another DesignBais Tip that’s done and just needs a little fine tuning, called Dynamic Color and Images. I think you’ll like it. I’ve made use of techniques already covered here to demonstrate some interesting new visual effects. Based on recent inqiuries in the DesignBais forum I’m also putting together an article on effective ways to dynamically customize your On Form Report headers, visual aspects of cells, etc. In the coming weeks I’ll also start writing about the new Version 4.0 enhancements and fixes… Stay tuned !