Personally, I try to avoid the use of tables for stuff like this - maintenance headache, harder to distribute or rebuild if necessary, and a change of version incompatibility if the software expects a field that isn't there, etc.

Two options are of course .ini files and registry entries. If you are using VFP 6.0, there are some decent classes in the FFC that abstract out a lot of the difficulty involved with these two things. If you want some examples I can give them to you.

If you are feeling adventurous, you could try XML. Has the advantage of containership in case you ever wanted to store many of something.

Of course, it all comes down to implementation...

Just an opinion.

>>>>Nothing wrong :) Just that you need to check existence and adjust rows using Insert/Delete in the same manner you'd check columns and use Alter Table to "insert/delete" columns if you want to make changes on updated app versions...
>>>
>>>
>>>True, but I don't need exclusive use of the table. I try to avoid that...
>>
>>Yes, but since this table is on the user's hard drive, EXCL is fine unless you allow more than one instance of your app. Also, I should mention another argument for the 1-row many-column table: there's no need to go LOCATE or SEEK a row, since you're always on row 1. There's no right/wrong on this issue, I'm only presenting some points why this method can be better for some situations :)
>
>That's true. I guess it wouldn't be too bad because I don't have that many things to save.
>
>Thanks,
>
>-Michelle