Wherefore art thou, database properties?

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.

Wherefore art thou, database properties?

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

Comments

Sign in or become a No Longer Set member to join the conversation.
Just enter your email below to get a log in link. (This will also subscribe you to my weekly newsletter.)