>>>OTOH, my bet is that most users wouldn't know how to open it. They'd doubleclick it and it would open in IE, readonly :).
>>>
>>>Ini file may be better. Even if one line is screwed up, the rest is still usable. And you can supply defaults within the same line where you read the values.
>>
>>I agree that INI is more "secure" than XML from the stand point of messing it up. But INI is so 90s <g>.
>
>Who cares. It ain't broken, and I won't try to fix it. And it's blazingly fast, while xml parsing grows squarely (i.e. the time to process grows with the square of its length, because it's read sequentially). Ini is also read sequentially, but it's much smaller and doesn't have all the fluff.
>
>>But I like Tamar's suggestion of checking who changed the file. She also suggested to store the "base" XML file to the .EXE which won't be practical (since each customer has a different settings). But I will see if I can store the "last" version of the XML file into some "hidden" place and being able to restore it, in case checksum does not match (as she suggested). Or if user corrupts the file.
>
>The checksum also won't match if a user made a legitimate and regular change, for example changing a phone number or fixing a typo in some name.

Both of your points - about INI being easier to read and less prone to be broken and that checksum may not be 100% reliable - are valid. So I need to consider all pros and cons. One thing that goes for (or in the column of pros) is that XML can be converted to cursor easier. In my application the XML (future XML) may have many settings and user has to select which one he/she wants to use. The program converts the XML into the cursor and with combo box allows user to select which setting is to be used (actually currently this is done by using DBF but the same has to work when I replace DBF with another format).