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.

Referenced articles

Image by Leroy Skalstad from Pixabay

UPDATE [2021-10-27]: Added link to the future post where I discuss my hg_csv example.  Added the "Referenced articles" section.