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.
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:
- Does the data apply globally?
- If no, use a variable or constant with more limited scope.
- Does the data ever change?
- If no, use a global constant.
- Do you want the data to be saved from one session to the next?
- If no, use a global variable or
TempVars.
- If no, use a global variable or
- Is the data user-independent?
- If no, use
SaveSettingto save to the user registry.
- If no, use
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
Mike Wolfe
Mike Wolfe
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.
