Properly Using Configuration Information/Files

[Wayne.C]

Store it all in a database.

[Nathan_S]

---

@Wayne.C wrote:

2.  XML and the OpenG Variant Config VI's work very well for .ini files.  Makes it very easy to add or delete entries from config file at later date.  An important consideration.

---

What do I do if I want to read an older version of my config file and the control used to write the config file has changed?  (say another key is added to a section or something).  This was my worry with using the type def to control the variant and store the data that way.  I would love to use classes for this, but, alas, doesn't look like we will be able to for this project.

[Wayne.C · Accepted solution]

Nathan_S,

#2 refered mainly to the code development phase.  If you think things will get added over time then I would consider using a database.

[pjr1121]

considering you want users to have access to the massive number of configuration options used at the time of their experiment, I'm thinking Wayne C. is right and databases are your solution.

When the user saves their data file, write the configuration values (along with the timestamp of the data save file) to a database.  Give all users read access to the database so they can check anything they need at a later time.  This should also prevent the situation of old config files getting lost/deleted.  Since the databases are searchable, they can easily retrieve the few values relevent to their post processing task instead of scanning through a large .ini file.

A bit more work on your end but the end users will be happy

[Wayne.C]

Expanding on the database idea a little more.  Consider what happens if multiple runs are made with the same exact configuration.  You don't really want to keep storing copies of the same configuration.  That's a waste of space.  You may want multiple timestamps/runs to point to the same configuration. A table could contain timestamps and references to configurations stored in a 'config' table.  A 'different' configuration isn't stored unless it is really a 'new' one that is not currently stored in the 'config' table.

[Nathan_S]

Excellent idea.  Didn't think of using a database.  I know how to talk to databases from LabVIEW, could you point me to a link on how to establish a database?  I've never put one together myself.  Do I need to know SQL or Oracle to put the DB together or are there some solutions for non-DB-savvy people?

Thanks again to everyone for the help.

[Wayne.C]

Nathan_S,

I currently use the Database Connectivity Toolkit from NI.  You can use ActiveX but I would imagine it can get complicated.  There may be an openG library of functions as well.  You will need to understand some basic principles about databases.

[pjr1121]

For a robust database, look up information on "normalizing" a database.  You'll probably only need to go to nf3 for this work (higher levels of normalization are often uneccesary).  

Essentially, you will have one table where each unique configuration is assigned a Config ID (you assign this and it will be used as the primary key of the database).  A second table will contain the timestamp and Config ID used for that data collection.  Since Config ID is a primary key in one table, it will be referred to as the Foreign Key in the other.  If there are any dependencies between entries of the configuration, they can be removed from the database to make them smaller.  (lets say you can multiply two columns to get the third; the third column is unneccesary). 

If you store User ID information, this will have to be handled as well (Unique User ID and a separate User Table)

(I'm new to databas creation as well so I apologize if this terminology is not quite correct)