You'll have to explain to the customer that "no matter what" carries too much weight. Are you going to protect against hardware failures? Fire? Floods? Under what level would an acceptable failure be, or an unacceptable failure? What specifically is the user looking to break? If the user gets smart enough and starts modifying your schemas, all bets are off, so, does that mean you have to start encrypting the database to keep their fingers out of the cookie jar? If files are being moved around and the database is pushed off somewhere else, do you keep a secret backup of the database somewhere else on the computer? Upload it to the cloud behind the users back? Do you somehow write the database directly onto the EXE and just make the user guess where the file is?
You can protect your software as best as you can acknowledging that users are inventive and will break your software, so the best you can do is defend against at least data entry issues, and perhaps, if you want to go the extra mile, DO save out to the cloud somewhere else for backup purposes. But there is a limit to what you can do without building a virtual Fort Knox around a simple phone book database application, and even then you can't save the data in case of a meteor strike. So sanitize your data on any database transaction, ensure that anything being put in and pulled out matches that of the constraint that the application expects (IE: User enters a letter instead of a number. Since SQLite will accept that, when reading the data out, your app may freak out). It is absolutely impossible to protect against EVERY contingency (Which is what "No Matter What" means), so definitions are going to have to be laid out about what the expectations are to be for failure defenses. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
