In my previous post, I talked about adding custom properties to the database object.  I covered how to do it, but did not go into any detail about why you might want to do it.  Let's remedy that now.

To be clear, I create very few custom database properties.  I went back through my projects to look for examples.  Here are my top three:

  • hg_csv: a comma-delimited list of local tables whose data I want to export for version control purposes (hg.exe is the Mercurial executable)
  • LocID: current location of the linked tables (dev vs. production; also used for programs installed for multiple clients)
  • PgmName: the friendly name of the program; if not set, the front-end's filename without extension is used

In reviewing these examples, I tried to come up with a more formal set of rules for why I would use a database property as opposed to something else, such as a global constant or user registry setting.  

If you answer Yes to the following questions, you have a good candidate for a database property:

  1. Does the data apply globally?
    • If no, use a variable or constant with more limited scope.
  2. Does the data ever change?
    • If no, use a global constant.
  3. Do you want the data to be saved from one session to the next?
    • If no, use a global variable or TempVars.
  4. Is the data user-independent?
    • If no, use SaveSetting to save to the user registry.

In a future post, I will talk more in-depth about some of the examples from my own work, including hg_csv and LocID.

Image by Leroy Skalstad from Pixabay