Jeff Justice wrote:
I have written an app that uses the built-in database. What are the pros and cons of using this for storage of prefs vs. a prefs file?
The basic problem with preference files is when the format (data content) changes and you have to implement backwards compatibility code in order to upgrade the preference file. If you use a flat file format like a text file or XML, you will need to deal with this. This is one reason why I exclusively use a database solution for my preference files. I have implemented a preference file classes based on a DB (in my case Valentina) that stores name-value pairs in the database. This abstraction allows me to change and upgrade preferences without having to write code to do that explicitly. If a preference becomes obsolete, I just leave it there (no reason to delete it). If I add a new preference, I just create a new name-value pair in the database. Since RB strings can contain binary data, you can put just about anything you want as the value. Also, the schema for my preference file never changes since it only defines the name-value pair. It is about as maintenance free as it gets. Also, every time a preference is read you have read in the entire file to get to the data. With a database approach, access is much faster (if that is what you need). When you write out a preference file using a text file or XML, you have to write out the entire contents each time. The database approach only writes out what has changed. I have create preference classes based on the database approach. Most of the work is done for you, and all you have to do is adapt it to your environment. It can be found at the following URL. http://www.truenorthsoftware.com/Realbasic/PreferenceDocument.html _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
