En/na Dennis Cote ha escrit: > Luca Olivetti wrote: > >> Well, I posted all the error messages I got back from sqlite, as well as >> the snippet of code I use to execute all my queries, but I can post more >> details if it can be useful (I'd only need to know which details could be). >> > > Ah, I'm sorry, I missed your first post. > > The original corruption may well have been caused by omitting the thread > safe option on the version of SQLite you were using.
Pheew, I hope it is really so. > I don't believe that there is any reason to expect a vacuum to correct a > corrupt database. Ah, ok, I thought that it did (at least it did with 3.3.8). > In general database corruption must be avoided, since > once it happens, it can't be corrected. That's my aim, yes, avoid the corruption, but I first must know what caused it. > The purpose of the vacuum operation is to reduce the size of the > database file by releasing any unused pages that may be contained in the > database file. If you are not concerned about disk space, there is no > need to vacuum ever. No, I'm not concerned about disk space, I just tried a vacuum (actually a vaccum after each detected corruption) as a misguided attempt of automatic recovery. > If you have valuable data in the database file you may be better off > adding an automatic backup process that saves backup copies of the > database file periodically. Then you can restore a backup and continue > from their if you detect a corrupt database. The data is only valuable as it is controlling a (relatively simple[*]) industrial machine that needs this data to work. The constantly changing data is relatively easy to introduce manually, but it's a long winded, manual, process (it takes around an hour, and you can't stop the line for an hour). I'm currently doing a backup every hour, and keeping the last day worth of backups, but it's not possible to work directly from the backup (you have to check manually what you have since the data changes every minute). [*]sorry for not explaining it before: it's an automated store in a car factory, where you put boxes full of pieces on one side, and take one one piece at a time from the other side depending on what's coming on the production line. Basically the database is used to keep track what's in the store and to decide what you need to fill it up with, based on historical data and on the next 200-300 cars coming down the line. > You might also want to add a process that does nothing but run integrity > checks on the database in order to try to determine when the corruption > occurred in case it happens again. This process would log the success or > failure of each check. This may greatly reduce the number of operations > you have to consider prior to a failure if the corruption happens again. I could consider it, but since I'm already logging everything and every couple of hours an external program is spawned (and it does an integrity check, as every process that opens the database) I don't think it's necessary. Thank you. Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
