Christian Smith wrote:
On Wed, 25 Jan 2006, Randy Graham wrote:
Hello,
Is it possible to copy tables from one memory database to another
without going through an intermediate disk database?
No, but you can copy the tables to be backed up to a temporary table, then
backup up
Jay Sprenkle wrote:
Sorry, I misunderstood you. Yes, selecting from one mem db and inserting
to another mem db would do the copy.
I'd thought of this, but wanted to avoid having to iterate through all
the rows and having explicit insert statements for each table, which
would require knowledge of
Gerry Snyder wrote:
Randy Graham wrote:
It sure would be nice to be able to attach one mem db to another.
-Randy
Didn't Jay Sprenkle's code do what you wanted?
Jay Sprenkle wrote:
sqlite> create table x(y text);
sqlite> insert into x(y) values('one');
sqlite> select * fr
Igor Tandetnik wrote:
Randy Graham wrote:
Igor Tandetnik wrote:
Randy Graham
<[EMAIL PROTECTED]>
wrote:
Is it possible to copy tables from one memory database to another
without going through an intermediate disk database?
Can't you just write a function that would run &
Igor Tandetnik wrote:
Randy Graham <[EMAIL PROTECTED]> wrote:
Is it possible to copy tables from one memory database to another
without going through an intermediate disk database?
Can't you just write a function that would run "select * from table"
on one db, and for e
Igor Tandetnik wrote:
Jay Sprenkle wrote:
Every time you open a :memory: database you get a separate instance,
identified only by its sqlite3* handle. I'm not sure if ATTACH would
work with :memory:, but even if it does it would just create a new,
empty in-memory database, not refer to the
Hello,
Is it possible to copy tables from one memory database to another
without going through an intermediate disk database?
Thanks,
-Randy
Thanks Dirk.
Yes, that would work.
Since I already have my tables logically spread across several files, I
think I'll just keep and empty db file 'templates' handy, delete the files
containing the tables I want cleared, and copy the templates to my working
db files.
Thanks for the suggestion.
[D. Richard Hipp wrote:]
>But that gives me an idea. If you need to delete an
>entire table quickly, why not put that one table in a
>separate database and ATTACH it. Then when you want
>to erase it all, DETACH the separate database, delete
>the file, then reinitialize the database and re-ATTACH
Wow, thanks for such a quick response !
>Disabling the journal would roughly half the amount
>of disk (flash) I/O required. If it currently takes
>2 minutes to delete, disabling the journal would
>reduce that to about 1 minutes. Still a long time.
Ok, thanks, that's good to know.
>Do you also
Hello,
Is there a way to delete all rows in a table without SQLITE generating
temporary journal files?
I'm using SQLITE in an embedded system with a *very* slow flash disk and
journal file creation for some operations (ie. deleting 1000s of rows from a
table) is killing performance. When I
Hello,
I'm using in memory tables that are copies of file tables.
I create the in memory tables by opening an in memory database, and
attaching a file database to it.
I then copy the table to my in memory database using something like
"create table t_mem as select * from t_file".
This gets the
12 matches
Mail list logo
