mr sql <[EMAIL PROTECTED]> 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 t
[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 structur
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
while you're backing it up.)
-- James
> -Original Message-
> From: Travis Daygale [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 26, 2007 1:05 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] .dump-n-reload vs. vacuum - which is better?
>
> Tangen
Travis Daygale <[EMAIL PROTECTED]> wrote:
> 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 unaff
That is useful to know (i.e. non-testing of the shell). Thanks.
Does "the core" include the tcl driver (what I use)? (It must- the driver is
in there and the testing is done with tcl, all of this being partly why I chose
tcl for my app- but I want to make sure I'm not somehow misunderstanding.
Travis Daygale <[EMAIL PROTECTED]> wrote:
> That is useful to know (i.e. non-testing of the shell). Thanks.
>
> Does "the core" include the tcl driver (what I use)? (It must- the driver is
> in there and the testing is done with tcl, all of this being partly why I
> chose tcl for my app- but I
[EMAIL PROTECTED] wrote:
It would probably not require more than a few lines of TCL code to
implement a "dump" command as a TCL proc.
I know that copying from one database to another is not the same as
dumping, but the following might be a useful starting point. It gets the
filenames of
I'll do that. I was troubled enough by that bug report and this new testing
info to be so motivated. :-)
If I think about it, the copy method has "filename" as an argument, and a dump
method for the tcl driver would need that too. All other methods I believe do
not need to specify the filesy
On Mon, 2007-02-26 at 17:05 -0800, Travis Daygale wrote:
> I'll do that. I was troubled enough by that bug report and this new testing
> info to be so motivated. :-)
This would be handy for Tcl developers.
In case you haven't noticed it yet, the SQL quote() function
in func.c will help with th
10 matches
Mail list logo