>>>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).
>
>If you want the users restricted to changes they can make from inside the form, then you don't really care. You can use simple cursortoxml and vice versa and you can even encrypt the xml, give it an obscure name, hide it in the chimney, anything you like. And the checksum is reliable as long as you calculate it on each save.
>
>It's the idea that the settings may be saved in a user-editable format where xml is likely to cause you trouble. Even ini files aren't moron proof - any touch in the section name makes the whole section unreadable, but xml is very sensitive - a single wrong keystroke makes the whole file syntactically wrong and the DOM parser refuses to read it. Now if you keep full programmatic control over the contents of the xml, then none of these need concern you.

You see the idea behind changing from DBF to XML (or INI for that matter) was to make it easier for end user manager (most likely IT) to change the setting. In case I am on vacation, traveling or whatever (since I am a one-man shop). At the same time I don't want the file to be changed by someone by accident or intentionally but without the need for the change. So my goal is kind of "conflicting".