I'm using 5.0, so that's out, and I'm not feeling adventurous. :)

I think a table would be ok in my case because I don't need to store much, and it won't change often. You have the same incompatibility problem with any place you change a table, so I'm not too worried about that.

Thanks,

-Michelle


>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