Here's an interesting approach. In larger systems, I've found there are usually a dozen or so "little" things that need to be tracked, such as what the last valid order number attempted was, or the date of the last access of a certain file. These are one-shot pieces of information that can go into the registry or an ini, but both of those methods involve different forms of risk and hassle. Instead, I use a database table called "Driver". (You can call it "Fred" if you want, it doesn't matter.) It is a one-record table, with fields specifically for the item in question. For instance, the driver for the above examples might contain the fields dr_lastorder(long integer) and dr_frm1access(date). The single record in the table contains the right values. Some of the advantages of this include:
1) You don't have to deal with the registry at all.
2) You don't have to support/track/distribute/protect a separate ini file just for this kind of storage.
3) You're in the database anyway, so it's not a big hassle.
4) Your data is protected more by being less accessible to the average user.
5) Since its in a table, the data types are correct, and don't have to be converted back and forth to strings.
6) Your "driver" data (most of which will relate to the database contents), are actually WITH the database contents.
I wrote a quick "PutToDriver" and "GetFromDriver" set of functions to make using this method easy, and put them in a module for Driver Functions. Then I just include a copy of that module in every project.