Installation, Setup and Deployment

The dumont dll is pretty easy to install. It's a simple matter of dropping the program files into a directory somewhere and running the regsvr32 on the DumontDLL.dll file. However, in order to use some of the automatic deployment features of Dumont you'll want to pick an installation directory that will be consistent and reliable. I have, so far, chosen to put my databases and other support files in C:/Commence. Therefore I will place Dumont in the C:/Commence/DumontDLL directory. Dumont defaults to this directory for its anticipated installation. Databases (in my circle of influence) are usually installed in C:/Commence/ThisDatabase and C:/Commence/ThatDatabase and so on. External Scripts are installed in the C:/Commence/Scripts directory. The reason for this is the use of agents that launch external programs requires that the external programs be in a specific known location. It is not uncommon to install a user database in an unpredictable location (this happens frequently) and doing so prevents some of these agents from running their scripts properly. So, that is the installation method I have chosen - to place everything in C:/Commence, C:/Commence/DumontDLL and C:/Commence/Scripts.

These default values can be overridden

In order to get the most out of dumont it is best to define a special Dumont category. This category allows dumont to manipulate and interact with the database to some degree.

The Dumont Category Definition
 Dumont Category Definition
 --------------------------
 Name:          Dumont
 Clarify Field: none
 Seperator:     " - "
 Index 1:       none
 Index 2:       none
 Duplicates:    No

  type        name            description
 +----------+---------------+--------------------------------------------------------
  Name      ' Name          ' required: Name Field
  Memo      ' Value         ' required: Value Field
  Text(20)  ' Group         ' optional: used to group items
  Number    ' Build         ' optional: used for version tracking
  Data      ' Data          ' optional: used to move data files through the workgroup
  Memo      ' Description   ' optional: used for documentation
  Check Box ' Run from Disk ' optional: flags when a script should be run from disk
  Connect   ' pRD->Employee ' optional: Connection to employee/user for read permission
  Connect   ' pWR->Employee ' optional: Connection to employee/user for write permission
The only required fields are the Name/Value pair. Dumont manages its own items so "Duplicate Items" is not even a requirement, but rather a suggestion. Dumont can be hooked into any category by setting the values in the database dumont.ini file.

Here is a Detailed description of those fields
  Type        Name            Kind
 +----------+---------------+----------
  Name      ' Name          ' REQUIRED
This field is the category 'Name' field. This field is coincident with regular DOS filename values. Therefore, Item names in Dumont are often called DumontGlobal.ini or dumontMWP.ini (my initials) or activeSVR.log (the server's log file). Dumont does a pretty good job of making sure these item names don't duplicate so it's not required to have the category disallow duplicates.
  Type        Name            Kind
 +----------+---------------+----------
  Memo      ' Value         ' REQUIRED
This is the Value field for Dumont. It is a memo field and can store just about anything (up to the 32000 byte limit imposed by Commence). Consider the 'Name' field the 'filename' field, and the 'Value' field the contents of the file. Some Dumont items will contain script code for the script include engine, and other Dumont items will contain var() field .ini file type settings. It just depends on the item.
  Type        Name            Kind
 +----------+---------------+----------
  Text(20)  ' Group         ' OPTIONAL
This is a Grouping field. It really has no functional impact on the system. Its intended purpose is to place a value in here so that all 'similar' items can be grouped in a report for ease of maintenance. For instance, Dumont can fetch a copy of each clients data.ini file. When those files are copied in to the Dumont category they are named dataMWP.ini - MWP being the initials of that particular user. That's all well and good, but in a report these individual items can be hard to spot. But, if you, the administrator, goes back and edits these items and places a group-value of data.ini in this 'Group' field, then all of those user items can be quickly spotted in a report.
  Type        Name            Kind
 +----------+---------------+----------
  Number    ' Build         ' OPTIONAL
This is a Build number, or a Version number, for the item in question. This is used as kind-of a sanity check on items since there's always that nagging question, "is this item up to date?". I have placed some script code in my Dumont form that auto-increments this value so that when I edit the include scripts this value increments also and I can insure the correct script is safely syncing around the workgroup.
  Type        Name            Kind
 +----------+---------------+----------
  Data      ' Data          ' OPTIONAL
At the time of this writing I'm not even sure if I'm using this field anymore. I believe it was intended as a workgroup variable-passing-answering mechanism that I never put to use.
  Type        Name            Kind
 +----------+---------------+----------
  Memo      ' Description   ' OPTIONAL
This is an item documentation field. Wouldn't it be nice to place documentation on Commence things such as fields, connections, reports, filters and such? Well, you can't! But, if you create a Dumont item for some purpose and you want to place some documentation on it, do that here.
  Type        Name            Kind
 +----------+---------------+----------
  Check Box ' Run from Disk ' OPTIONAL
This is a field that is used as part of the scripting engine. Dumont can store items of any type - this includes form script include files. Normally the Dumont scripting engine searches for scripts in the Dumont category under the 'Name' given by the request, it will return that item value. That means, Form script include files need to be maintained in the Dumont category. However, what if you have your own script editor, or file editor, and you don't want to have to be writing scripts inside a Commence Memo field? Check this Box! This causes the scripting engine to look first on Disk in the Scripts directory for the script that you are editing and load that instead of the item stored in the Dumont category.
This is handy for a couple of reasons. If you want to debug your scripts or make some changes to your scripts without those items syncing all around the workgroup you can turn this option ON and begin making changes to the Disk file rather than the Commence item. This way you can leave workgroup synchronization turned on and edit your include script from disk and not disrupt the rest of the work group. When you're done editing, come back to this item, turn this option off, and copy the code on disk back in to this item's Value field (I have some script on the Dumont form that does this automatically).
  Type        Name            Kind
 +----------+---------------+----------
  Connect   ' pRD->Employee   OPTIONAL
  Connect   ' pWR->Employee   OPTIONAL
These two fields are totally optional and are part of the Read/Write permissions module, but I'll discuss them briefly here. Dumont Items can (and should) be selectively synced around the workgroup. Items intended for one user should be given Read (and/or Write) permissions for only that user. Users also can (and will) create their own Dumont items as well, and these items will belong to only that user. The permissions should be set on these items accordingly to control who has what capabilities over any item.
In particular, there is an item that Dumont expects to see called dumontGlobal.ini. This item is exactly what it suggests it is - part of the global (workgroup wide) control settings. In VB the contents of this item can be got to by calling upon
 msgbox dfrm.DB.dumGlobal("varName")
The values stored in this item are in a .ini file format (hence the name). And Dumont uses this item extensively to control its behaviour. However, typically this dumontGlobal.ini item is set up a Read-Only for all users, since we don't want just any user mucking around with the Global settings of the application.
Dumont also benefits from having an agent or two to support some of its automatic functions. Unfortunately Dumont doesn't have the ability to author agents directly (yet) so you'll have to set this up yourself.

Agent: Dumont-Item-Update
 Agent Definition
 -----------------+-----------------------------------
 Name:             Dumont Item Update
  Trigger:         Item Saved In Dumont
   Trigger if:     Added, Edited, as Shared, as Local
   Category:       Dumont
   Filter:         no
   Options:        Detail Form, Synk Link, Workgroup
  Conditions:      none
  Actions:         Edit Item
   Using Values:   From Trigger
   Display Items:  Yes
   Field Values:   none
   Form:           DumontScript
   Promote Shared: no
Deprecated:
(replaced with permissions module) If you are going to employ item permission control, you are going to have to add another agent to your database to handle the permissions. This agent should perform a post-edit on items added to Dumont.
Agent: Dumont-Item-Add
 Agent Definition
 -----------------+-----------------------------------
 Name:             Dumont Item Add
  Trigger:         Item Saved in Dumont
   Trigger if:     Added, as Local
   Category:       Dumont
   Filter:         no
   Options:        ALL
  Conditions:      none
  Actions:         Edit Item
   Using Values:   From Trigger
   Display Items:  Yes
   Field Values:   pRD=(-Me-), pWR=(-Me-)
   Form:           none
   Promote Shared: yes
This agent is designed to add connections to this new Dumont item to the employee/user table, granting this user read and write access. This allows users who create items in the Dumont category to be able to edit items they created.




~ ~ ~ ~ ~ ~
Source Code without Comments is like a Cranberry Garland
without the berries. Comment your Code!
 
Commence Database User Support Group Forum
http://newsgroup.showoff-db.org/
~ ~ ~ ~ ~ ~
Author: Mark Petryk
Lorimark Solutions, LLC
mark@lorimarksolutions.com