What application are you using to build your application? You mentioned Visual Studio, so .NET? If so, are you using the SQLite library from system.data.sqlite.org? Are you using c# or vb?
My settings table is a lot simpler. id, setting and value. 3 columns. Possibly 4, adding a 'code' column. The 'setting' column holds the full setting you want to store, eg, 'main form height', or 'main form windowstate'. I can have user settings in this via 'chris/main form height'. I can then store that setting name as a constant in my application, so its accessible via Intellisense. Doing a series of quick database lookups is relatively cheap. You can also group the settings if need be, so 'main form/height' and 'main form/windowstate' so you could pull out a group of settings with one database query. Happy to link you to a sample if needed. A simple (although bloaty!) database class can be used for the mundane database work - reading, creating, editing and deleting records. I tend to ensure my databases have unique rowIds, and use these for the glue for relationships. Thanks, Chris On Thu, Dec 20, 2018 at 3:37 AM Roger Schlueter <se...@cox.net> wrote: > On 12/19/2018 10:02, Jens Alfke wrote: > >> On Dec 18, 2018, at 7:46 PM, Roger Schlueter <se...@cox.net> wrote: > >> > >> I am starting work on a prototype application so this might be an > excellent opportunity to use SQLite for my application file format. Part > of this would be the saving and restoring of GUI elements such as window > positions and sizes, control states, themes, etc. > > IMHO something like JSON is a good format for such config/preference > data, instead of having a table with a column for every pref. During > development you’ll often be adding new prefs, and it’s a pain to have to > update a CREATE TABLE statement every time you add one. It’s even more of a > pain to have to handle a schema change with ALTER TABLE in an app upgrade > that adds a new pref. If you use JSON you just have to come up with a new > string to use as the key for each pref. It’s also easy to have structured > values like arrays or nested objects. (FWIW, his is essentially the way > that Apple OS’s manage app prefs via the NSUserDefaults class.) > > JSON or XML: Two sides of the same coin. If I wanted to go the > separate file approach, I'd just use the settings class of Visual > Studio since all the required plumbing is already in place. > > More importantly, as I noted this is a prototype (read: test) > application so it is a good opportunity for me to get my feet wet > with SQLite since I'm a n00b with it. > > > Of course you can save the JSON in the database file. Just create a > ‘prefs’ table with one blob column for the JSON. > > > > A related solution is to store each named pref as a row in the ‘prefs’ > table, identified by a ‘key’ column. > > In fact, this statement makes the concerns you raised in the first > paragraph moot. A simple table with four columns: > > 1. Window name > 2. Control name > 3. Control property > 4. Property value > > covers all the possibilities, no ALTER table necessary. If I want > to enable per user values, I'd just add a User column. > > In short, the design part is easy IMO. I'm still hoping to see some > examples since, surely, I'm not the first person to go this route. > > > > —Jens > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
