Tangentially, but hopefully in keeping with this thread, for the 3.3.9 release, the change log shows: Fixed the ".dump" command in the command-line shell to show indices, triggers and views again.
There was apparently a bug there. I was unaffected but _apparently_ would have been hurt had I not skipped some versions. (I have A LOT of important triggers for foreign key handling.) Should we feel insecure about dump? I know sqlite3 is in development, but overall, is the .dump command usually reliable (is there anything about the relevent code that might make the bug reports not the full story)? Are there recommended ways of doing backups that would be more reliable? Thanks in advance, -T mr sql <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: mr sql wrote: > I found out that doing a: > > sqlite3 my.db .dump > mydump.sql > rm my.db > sqlite3 my.db < mydump.sql > > is faster than doing a VACUUM on my.db. > > Are there any advantages of doing one over the other? My goal is to keep the > database's structures in their best shape for performance and integrity. So > I want to run this process every once in a while. > Have you tried running VACUUM out of the latest code in CVS? It should be faster and it should do a better job of defragmenting the database. -- D. Richard Hipp Not sure, I am using 3.3.13 on winxp sp2, using the downloadable (precompiled) sqlite3.exe and sqlite3.dll. Is there any 3.3.14 on the way? For some reason, when I do my own compilations, sqlite3 (both the exe and dll) crash randomly so I prefer to use the precompiled versions. jp --------------------------------- 8:00? 8:25? 8:40? Find a flick in no time with theYahoo! Search movie showtime shortcut. --------------------------------- Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.
