Dear msimmxx- (name?)
I would think a table that looked like:
Object (text or numeric code for object type, including "application")
ObjectName
PropertyName
Setting
Setting will have to be text, and you'll have to "morph" the text string to the
appropriate data type. You might want to include a DataType column as well.
John Viescas, author
Microsoft Office Access 2010 Inside Out
Microsoft Office Access 2007 Inside Out
Building Microsoft Access Applications
Microsoft Office Access 2003 Inside Out
SQL Queries for Mere Mortals
http://www.viescas.com/
(Paris, France)
-----Original Message-----
From: MS_Access_Professionals@yahoogroups.com
[mailto:MS_Access_Professionals@yahoogroups.com] On Behalf Of msimmsx
Sent: Wednesday, October 19, 2011 12:42 PM
To: MS_Access_Professionals@yahoogroups.com
Subject: [MS_AccessPros] Persistence Framework
I'm about to embark on a mini-project to create a set of functions and tables
that will store any application's important settings. The settings could be at
the following levels: application (title, color theme, etc), object (default
form settings, report settings, etc, object and user (the key of a form's last
record viewed, user default value preferences, etc), and finally user-level
(initial form to open upon start-up, etc).
Has anyone attempted this before ? I built a similar framework using
SaveSettings, GetSettings but I was unhappy with that result for several
reasons: it was registry-based, the settings couldn't be easily cloned or
transferred, etc.
Database properties is another option, but I think it is way too unwieldy for
the flexibility of storing and retrieving these settings at all of the various
levels as outlined above.
Comments/suggestions greatly appreciated.
------------------------------------
Yahoo! Groups Links
Tidak ada komentar:
Posting Komentar