[sqlite] .dump

I noticed that the .dump command in the CLI doesn't contain the "user_version" and "application_id" fields. I don't know whether this is intentional, but would you consider including these values in the output of .dump? ___ sqlite-users mailing list

Re: [sqlite] SQLite .dump

Simon Slavin wrote: > I'm sorry, but I don't see a question in your post. As intended. It was just a statement based on observation, with regard to SQLite .dump, my GUI dump, and other database dump outputs. MySQL also uses a short version without specifying column names, but does quo

Re: [sqlite] SQLite .dump

s in your INSERT statements. > and using the database's > identifier quoting character. It does that at need already: sqlite> create table "x y" ("a b" INTEGER); sqlite> .dump PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE IF

Re: [sqlite] SQLite .dump

I'm sorry, but I don't see a question in your post. Are you suggesting that the SQLite command-line tool has a bug ? Are you suggesting that Ajqvue has a bug ? Simon. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

[sqlite] SQLite .dump

://ajqvue.com/docs/Manual/Ajqvue_Manual.html#Preferences_Data_Export_SQL Preferences Data Export SQL Always specifying the column names list and using the database's identifier quoting character. danap. === sqlite> .dump PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TA

Re: [sqlite] .dump command and user_version

On 2018-03-29 12:47, Wout Mertens wrote: > I noticed that `.dump` does not output the user_version pragma. It > seems to me that that is part of the database data? I have run into this too. I was trying to transport Mozilla browser "places" database this way, and it turned out their code cares

Re: [sqlite] .dump command and user_version

On Thu, Mar 29, 2018, 8:18 AM Richard Hipp wrote: > On 3/29/18, Scott Robison wrote: > > It seems a > > reasonable to suggestion to add it. > > Version 3.23.0 is in bug-fix-only mode. It'll have to wait. > Of course. I wasn't suggesting that it

Re: [sqlite] .dump command and user_version

On 29 Mar 2018, at 3:10pm, Scott Robison wrote: > Yet as he said, user_version is data. It can be queried and can be > checked to make decisions about what to do with the data. It seems a > reasonable to suggestion to add it. On consideration, I see the point. Would

Re: [sqlite] .dump command and user_version

On 3/29/18, Scott Robison wrote: > It seems a > reasonable to suggestion to add it. Version 3.23.0 is in bug-fix-only mode. It'll have to wait. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list

Re: [sqlite] .dump command and user_version

On Thu, Mar 29, 2018 at 6:56 AM, Simon Slavin wrote: > > > On 29 Mar 2018, at 1:47pm, Wout Mertens wrote: > >> I noticed that `.dump` does not output the user_version pragma. It seems to >> me that that is part of the database data? >> >> I don't

Re: [sqlite] .dump command and user_version

On 29 Mar 2018, at 1:47pm, Wout Mertens wrote: > I noticed that `.dump` does not output the user_version pragma. It seems to > me that that is part of the database data? > > I don't actually use it, but it might be interesting to add this for > completeness? .dump is

[sqlite] .dump command and user_version

I noticed that `.dump` does not output the user_version pragma. It seems to me that that is part of the database data? I don't actually use it, but it might be interesting to add this for completeness? sqlite> .dump PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; COMMIT; sqlite> pragma user_v

Re: [sqlite] .DUMP displays floats differently from SELECT

Hello, On 2018-01-22 13:00, Iulian Onofrei wrote: I have a "REAL" column with float values having up to 2 decimals, and using ".dump" with the latest version incorrectly converts them like this: "0.0" -> "0.0" "0.05" -> "0.050002775" > [...] Did you consider an using of INTEGERs

Re: [sqlite] .DUMP displays floats differently from SELECT

> On Jan 22, 2018, at 10:12 PM, Cezary H. Noweta wrote: > > I suppose that 20 digits is taken from the fact: 64ln(2)/ln(10)=19.2..., > however, for 64bit mantissa (long double) it is not enough (to be represented > exactly), for 53bit mantissa it is too many. Besides

Re: [sqlite] .DUMP displays floats differently from SELECT

Hello, On 2018-01-22 21:33, Keith Medcalf wrote: The long and the short of it is that the output of .DUMP is correct. I would say that the output is ``too correct''. ``.dump'' displays 20 meaningful digits. Let's look at the 17 meaningful digits. Mantissa divides every exponential range

Re: [sqlite] .DUMP displays floats differently from SELECT

FYI. There's no need to pin back the whole db version just to get the old style dbdump format. The original dump is available from the distribution as a standalone program here: http://www.sqlite.org/src/artifact/819eb33f6ff788a4 --dbdump.c-- ** If this file is compiled with -DDBDUMP_STANDALONE

Re: [sqlite] .DUMP displays floats differently from SELECT

FYI. There's no need to pin the whole db version back to get original dbdump formatting. The original distribution standalone dump is still available in its full glory here: http://www.sqlite.org/src/artifact/819eb33f6ff788a4 --dbdump.c-- ** If this file is compiled with -DDBDUMP_STANDALONE

Re: [sqlite] .DUMP displays floats differently from SELECT

...@mailinglists.sqlite.org] On Behalf Of Iulian Onofrei >Sent: Monday, 22 January, 2018 05:01 >To: sqlite-users@mailinglists.sqlite.org >Subject: Re: [sqlite] .DUMP displays floats differently from SELECT > >Hi, > >This is clearly a bug, as it outputs incorrect and different outpu

Re: [sqlite] .DUMP displays floats differently from SELECT

I reported this same issue in May 2017 (http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/2017-May/072714.html) I too consider this a problem (diffing dumps is one good reason why) but, unfortunately, this was an intentional change by this check-in: [7359fcac] Increase the

Re: [sqlite] .DUMP displays floats differently from SELECT

in the > FAQ http://www.sqlite.org/faq.html#q16 > > > -Original Message- > From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] > On Behalf Of Iulian Onofrei > Sent: Monday, January 22, 2018 7:01 AM > To: sqlite-users@mailinglists.sqlite.org > Subject: R

Re: [sqlite] .DUMP displays floats differently from SELECT

in the FAQ http://www.sqlite.org/faq.html#q16 -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Iulian Onofrei Sent: Monday, January 22, 2018 7:01 AM To: sqlite-users@mailinglists.sqlite.org Subject: Re: [sqlite] .DUMP displays floats

Re: [sqlite] .DUMP displays floats differently from SELECT

Hi, This is clearly a bug, as it outputs incorrect and different output from the previous versions. I have a "REAL" column with float values having up to 2 decimals, and using ".dump" with the latest version incorrectly converts them like this: "0.0" -> "0.0" "0.05" -> "0.050002775"

Re: [sqlite] .DUMP displays floats differently from SELECT

Tony Papadimitriou wrote: > Apparently, this was an intentional change by this check-in : > > [7359fcac] Increase the number of significant digits in floating point > literals on ".dump" output from the shell. > > I don't know what problem this change actually solved Scott Robinson already

Re: [sqlite] .DUMP displays floats differently from SELECT

Apparently, this was an intentional change by this check-in : [7359fcac] Increase the number of significant digits in floating point literals on ".dump" output from the shell. I don't know what problem this change actually solved (as in my case it introduced one) but for my own copy I changed

Re: [sqlite] .DUMP displays floats differently from SELECT

sqlite> select * from xxx; --EQP-- 0,0,0,SCAN TABLE xxx x 1.23 Run Time: real 0.004 user 0.00 sys 0.00 sqlite> .dump PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE xxx (x primary key); --EQP-- 0,0,0,SCAN TABLE xxx INSERT INTO xxx(x) VALUES(1.2299822); COMMIT; s

Re: [sqlite] .DUMP displays floats differently from SELECT

In a previous message I suggest that behaviour under macOS changed between SQLite 3.16.0 and SQLite 3.18.0. I then received information from a lurker who uses Windows 7: SQLite version 3.17.0 2017-02-13 16:02:40 INSERT INTO "xxx" VALUES(1.23); … SQLite version 3.18.0 2017-03-28 18:48:43

Re: [sqlite] .DUMP displays floats differently from SELECT

> -Original Message- > From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On > Behalf Of Simon Slavin > Sent: Wednesday, May 03, 2017 12:30 PM > To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> > Subject: Re: [sqlite] .DUMP dis

Re: [sqlite] .DUMP displays floats differently from SELECT

esults of reading the dump file back in produces a different value to the original INSERT, that’s a problem. So I tried it: SQLite version 3.16.0 2016-11-04 19:09:39 Enter ".help" for usage hints. sqlite> create table xxx(x); sqlite> insert into xxx values(1.23); sqlite> se

Re: [sqlite] .DUMP displays floats differently from SELECT

On May 3, 2017 8:07 AM, "Tony Papadimitriou" wrote: While trying to search/replace some text from an SQLite3 dump I noticed that, unfortunately, .DUMP does not produce the exact same numbers as a plain SELECT on the same values. I know all about expected floating point

[sqlite] .DUMP displays floats differently from SELECT

While trying to search/replace some text from an SQLite3 dump I noticed that, unfortunately, .DUMP does not produce the exact same numbers as a plain SELECT on the same values. I know all about expected floating point inaccuracies, but I don’t see why it should matter in this case as we have

[sqlite] .DUMP output compatibility

ils and https://sourceforge.net/projects/unxutils/ -- Regards, Kees Nuyt >-Original Message- >From: Richard Hipp >Sent: Friday, May 06, 2016 1:55 AM >To: SQLite mailing list >Subject: Re: [sqlite] .DUMP output compatibility > >On 5/5/16, Tony Papadimitriou wrote: >> Is it p

[sqlite] .DUMP output compatibility

Windows! -Original Message- From: Richard Hipp Sent: Friday, May 06, 2016 1:55 AM To: SQLite mailing list Subject: Re: [sqlite] .DUMP output compatibility On 5/5/16, Tony Papadimitriou wrote: > Is it possible for .DUMP to produce table/field names quoted with ` > (backquote) i

[sqlite] .DUMP output compatibility

Is it possible for .DUMP to produce table/field names quoted with ` (backquote) instead of ? (double quote) for compatibility with MySQL? Or is this already adjustable by some setting I missed? Thank you.

[sqlite] .DUMP output compatibility

On 5/5/16, Tony Papadimitriou wrote: > Is it possible for .DUMP to produce table/field names quoted with ` > (backquote) instead of ? (double quote) for compatibility with MySQL? > Or is this already adjustable by some setting I missed? Pipe the output through sed

[sqlite] .DUMP output compatibility

On May 5, 2016, at 4:56 PM, Tony Papadimitriou wrote: > > Windows! So install Cygwin. There may be more to it than the quoting style. I?ve used the following script for moving data the other direction (MySQL to SQLite): https://gist.github.com/esperlu/943776 You might have to create the

[sqlite] dump only data, change schema, reload

gt;out, "ANALYZE sqlite_master;\n"); } -??? if(data.cnt) fprintf(p->out, "COMMIT;\n"); ?? }else ? ?? if( c=='h' && strncmp(azArg[0], "headers", n)==0 ){ @@ -3717,7 +3703,6 @@ memcpy(, p, sizeof(data)); data.showHeader = 0; data.cMode = d

[sqlite] dump only data, change schema, reload

On Wed, Mar 23, 2016 at 1:02 PM, Keith Medcalf wrote: > > Do you mean something like this, perchance? This sets .mode insert > then does a select ..., which outputs the selected data in the > form of INSERT statements into a table called . The .mode list > just allows other commands to be

[sqlite] dump only data, change schema, reload

On Wed, Mar 23, 2016 at 10:50 AM, Luca Ferrari wrote: > ...The problem is that .dump provides data and schema, while I'd like to > have data only. > Other commands like .clone and .backup works pretty much the same, as > far as I understand. > > This leads me to either use awk/sed to manipulate

[sqlite] dump only data, change schema, reload

Hi all, I've a few hundreds sqlite3 database files, all almost equals except for some constraint that has changed during time. As I know, there is no way to alter constraint (e.g., unique indexes), and therefore I have to migrate data to a new schema version. That is possible because data will fit

[sqlite] dump only data, change schema, reload

f Of Luca Ferrari > Sent: Wednesday, 23 March, 2016 03:50 > To: SQLite > Subject: [sqlite] dump only data, change schema, reload > > Hi all, > I've a few hundreds sqlite3 database files, all almost equals except > for some constraint that has changed during time. > As

Re: [sqlite] sqlite dump makes wrong "CREATE VIEW" order

On 17 Apr 2014, at 3:42pm, Igor Tandetnik wrote: > If there's a bug anywhere in this, I'd say it's the fact that SQLite allowed > "DROP VIEW v2" statement to proceed. Agreed. Is there a similar bug if you try to drop a table that a FOREIGN KEY depends on ? Simon.

Re: [sqlite] sqlite dump makes wrong "CREATE VIEW" order

On 4/17/2014 12:43 AM, Tyumentsev Alexander wrote: sqlite in some cases dumps views in wrong order. Interesting situation. My take on it would be that dump is a simple little tool designed to help move a database file from one place to another. In tricky situations, some editing of its

Re: [sqlite] sqlite dump makes wrong "CREATE VIEW" order

On 4/17/2014 3:43 AM, Tyumentsev Alexander wrote: CREATE VIEW v2 as select id1 from test where id1; CREATE VIEW v1 as select t1.id2 from test as t1 LEFT JOIN v2 ON t1.id2=v2.id1; DROP VIEW v2; Is it the user responsibility to follow all dependencies and recreate "VIEW" tree ? I'd say it's the

Re: [sqlite] sqlite dump makes wrong "CREATE VIEW" order

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/04/14 00:43, Tyumentsev Alexander wrote: > Is it the user responsibility to follow all dependencies and recreate > "VIEW" tree ? The dumping is happening in the order that the views were created. This approach generally works, but fails in

[sqlite] sqlite dump makes wrong "CREATE VIEW" order

sqlite in some cases dumps views in wrong order. how to reproduce on linux: 1) Make the test database with 2 "view". v1 depends on v2. Recreate v2 cat <<_EOF_ | sqlite3 test.sqlite PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE test ( "id1" integer(8,0), "id2" integer(8,0), "id3"

[sqlite] dump command in shell using test_demovfs

Hi, I'm trying to create a VFS for SQLite 3.7.17 porting. I started from testdemo_vfs.c using it first under linux compiling and link it (-DSQLITE_THREADSAFE=0 at compile time) Using this VFS (the behavior is the same on my embedded platform and under linux) I can create and access a db and

Re: [sqlite] .dump - what isn't preserved?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/13 04:24, Dave McKee wrote: > What else isn't losslessly maintained in a dump -> load cycle? Various database settings and any strings with nuls in them. Also the sqlite shell expects to be loaded into a clean database. For example it

Re: [sqlite] .dump - what isn't preserved?

On 1 Mar 2013, at 12:24pm, Dave McKee wrote: > I'm considering working with a dump of the SQL database, and I'm anxious to > make sure that nothing gets lost in the transformation. I assume you're talking about the '.dump' function of the shell tool, which creates a

[sqlite] .dump - what isn't preserved?

I'm considering working with a dump of the SQL database, and I'm anxious to make sure that nothing gets lost in the transformation. I'm aware that the database will effectively be vacuumed and that rowids won't be preserved. I'm happy about the first and can live with the second. What else isn't

Re: [sqlite] .dump ... [was: Please test the latest SQLite snapshot]

On 3 Dec 2012, Richard Hipp wrote: ... You can get a tarball or ZIP archive of the latest raw sources from Fossil at http://www.sqlite.org/src/info/trunk I notice that in this (3.7.15 pre-release snapshot) version of the shell the .help out for the .dump command reads: .dump ?TABLE? ...

Re: [sqlite] Dump a memory DB

On 31 Oct 2012, at 2:25pm, Andrea Peri wrote: > From the sqlite3 console, is possible to dump on disk a memory DB ? Use the .dump command. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org

Re: [sqlite] Dump a memory DB

You can use the .backup command: http://www.sqlite.org/sqlite.html *Jonas Malaco Filho* 2012/10/31 Andrea Peri > Hi, > > From the sqlite3 console, is possible to dump on disk a memory DB ? > > Thx, > > -- > - > Andrea Peri > . . . . . . . . . > qwerty

[sqlite] Dump a memory DB

Hi, >From the sqlite3 console, is possible to dump on disk a memory DB ? Thx, -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ sqlite-users mailing list sqlite-users@sqlite.org

Re: [sqlite] .dump of utf16 database

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin Ryde wrote: > Or no doubt by querying it out, "sqlite3 old.db 'pragma encoding'". > But that's something .dump could helpfully do itself, could it? The SQLite shell can't read your mind :-) Adding something like this would require yet another

Re: [sqlite] .dump of utf16 database

Roger Binns writes: > > The only effect is what happens behind the scenes. I thought that might be so. > echo 'pragma encoding="UTF-16";' Or no doubt by querying it out, "sqlite3 old.db 'pragma encoding'". But that's something .dump could

Re: [sqlite] .dump of utf16 database

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin Ryde wrote: > Perhaps it doesn't matter to anything. The only effect is what happens behind the scenes. If you primarily use the - -16 interfaces to bind and retrieve text then the database also being utf16 means you avoid SQLite doing a

[sqlite] .dump of utf16 database

I was trying some .dump round-trips like sqlite3 old.db .dump | sqlite3 new.db and noticed if old.db is utf16, ie. pragma encoding=utf16, then new.db doesn't get that but instead is utf8. Is that intentional? Would slipping a pragma into the .dump output preserve the db coding? (I don't

Re: [sqlite] sqlite .dump does not save PRAGMA user_version

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Schubert wrote: > When creating a dump with sqlite .dump, it will not save the user_version. The problem is that the usage of the user_version is not known. It could be harmless to dump or it could cause problems on a restore. > PS: ple

Re: [sqlite] dump in-memory db to file in tcl

Hello! 1. Use tcl backup API The "backup" method The "backup" method makes a backup copy of a live database. The command syntax is like this: dbcmd backup ?source-database? backup-filename The optional source-database argument tells which database in the current connection should be backed

Re: [sqlite] dump in-memory db to file in tcl

Ned Fleming wrote: > Is it possible to dump an in-memory sqlite database (or table?) to a > file from within Tcl? > > I create it like so: > > sqlite3 dbFireData :memory: > > and insert a bunch of records, and then commit. Is there reason not to attach a file (old or new), and either

[sqlite] dump in-memory db to file in tcl

Is it possible to dump an in-memory sqlite database (or table?) to a file from within Tcl? I create it like so: sqlite3 dbFireData :memory: and insert a bunch of records, and then commit. I have tried the following (and variations) -- but no go, kokomo. ($fileOut3 is a handle to a

Re: [sqlite] .dump and transactions

On Monday, 12. January 2009 14:20:40 Thomas Jarosch wrote: > If an open transaction would block the dump of the database, > then the second command line tool should busy wait until a timeout occurs > or atleast return an error message. I finally tracked this down by testing sqlite 3.6.10 on my

Re: [sqlite] .dump and transactions

On Monday, 12. January 2009 13:52:47 P Kishor wrote: > > Here's a short example to reproduce the problem: > > > > sqlite3 test.db > > create table test (name varchar(16)); > > begin transaction; > > insert into test values ('test'); > > did you forget to COMMIT here? Thanks for your reply. In

Re: [sqlite] .dump and transactions

On Mon, Jan 12, 2009 at 4:30 AM, Thomas Jarosch wrote: > On Friday, 9. January 2009 10:34:32 Thomas Jarosch wrote: >> I run a small script every night via cron to backup a database >> using the ".dump" statement. SQlite version is 3.6.6.2 on Linux. >> >> Normally

Re: [sqlite] .dump and transactions

On Friday, 9. January 2009 10:34:32 Thomas Jarosch wrote: > I run a small script every night via cron to backup a database > using the ".dump" statement. SQlite version is 3.6.6.2 on Linux. > > Normally this script works fine and from time to time > I get a backup file that looks like this: >

[sqlite] .dump and transactions

Hello together, I run a small script every night via cron to backup a database using the ".dump" statement. SQlite version is 3.6.6.2 on Linux. Normally this script works fine and from time to time I get a backup file that looks like this: --- BEGIN TRANSACTION; END TRANSACTION;

Re: [sqlite] .dump often fails silently

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kees Nuyt wrote: > Did you try > .bail on > It won't change the destination of error messages, but at > least it aborts the sql script at the first error it > encounters. That is not true of errors returned by sqlite3_exec when doing .dump.

Re: [sqlite] .dump often fails silently

On Sat, 8 Nov 2008 11:44:23 +1100, raf <[EMAIL PROTECTED]> wrote in General Discussion of SQLite Database : >but that's my point. >i'm not getting any errors. >it's just failing silently. Did you try .bail on ? It won't change the destination of error messages,

Re: [sqlite] .dump often fails silently

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 raf wrote: >> printing error messages to stderr rather than ignoring >> them shoulden't require an overhaul. It does though. You need to fix every place where an error can be detected and take an appropriate action. One extra printf is not the

Re: [sqlite] .dump often fails silently

Roger Binns wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > raf wrote: > > the sqlite3 .dump command (version 3.4.2 and earlier) often fails > > silently. i.e. it produces a file containing nothing but: > > The code for the shell mostly just runs sqlite3_exec and often ignores >

Re: [sqlite] .dump often fails silently

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 raf wrote: > the sqlite3 .dump command (version 3.4.2 and earlier) often fails > silently. i.e. it produces a file containing nothing but: The code for the shell mostly just runs sqlite3_exec and often ignores the return code (unless it is

[sqlite] .dump often fails silently

hi, the sqlite3 .dump command (version 3.4.2 and earlier) often fails silently. i.e. it produces a file containing nothing but: BEGIN TRANSACTION; COMMIT; and its exit code is zero (falsely indicating success). my backup script has been misinterpreting this as evidence of database

Re: [sqlite] Dump w/o Schema

Is there a way to merge these in such a way that I could make this from a system call? For example, let's say I want to create this dump file from a Perl or shell script using a system call. Can I do that? Thanks, Mark On Jan 15, 2008 4:59 PM, Rich Shepard <[EMAIL PROTECTED]> wrote: > On Tue,

Re: [sqlite] Dump w/o Schema

On Tue, 15 Jan 2008, Rob Sciuk wrote: Is there a way to dump out the contents of the database w/o having the CREATE TABLE statements? For example, I can do the following: However, foo.dmp contains all of the CREATE TABLE statements. I just want all of the INSERT INTO statements associated

Re: [sqlite] Dump w/o Schema

On 1/15/08, Mark Riehl <[EMAIL PROTECTED]> wrote: > I'm coming from a MySQL background and the mysqldump utility supports > schema-only, sqlite> .mode filename sqlite> .s > data-only, sqlite> .mode filename sqlite> .mode csv|tabs sqlite> .dump > and schem

Re: [sqlite] Dump w/o Schema

I'm coming from a MySQL background and the mysqldump utility supports schema-only, data-only, and schema plus data dumps. I thought that there was an SQLite trick I was missing somewhere. Mark On Jan 15, 2008 4:10 PM, Rob Sciuk <[EMAIL PROTECTED]> wrote: > > > On Tue, 15 Jan 2008, Mark Riehl

Re: [sqlite] Dump w/o Schema

On Tue, 15 Jan 2008, Mark Riehl wrote: Is there a way to dump out the contents of the database w/o having the CREATE TABLE statements? For example, I can do the following: sqlite3 foo.db .dump > foo.dmp However, foo.dmp contains all of the CREATE TABLE statements. I just want all of the

Re: [sqlite] Dump w/o Schema

Mark Riehl wrote: Is there a way to dump out the contents of the database w/o having the CREATE TABLE statements? For example, I can do the following: sqlite3 foo.db .dump > foo.dmp However, foo.dmp contains all of the CREATE TABLE statements. I just want all of the INSERT INTO statements

Re: [sqlite] Dump w/o Schema

On Jan 15, 2008 2:37 PM, Mark Riehl <[EMAIL PROTECTED]> wrote: > Is there a way to dump out the contents of the database w/o having the > CREATE TABLE statements? For example, I can do the following: > > sqlite3 foo.db .dump > foo.dmp > You could do something like on Unix: sqlite3 foo.db .dump

[sqlite] Dump w/o Schema

Is there a way to dump out the contents of the database w/o having the CREATE TABLE statements? For example, I can do the following: sqlite3 foo.db .dump > foo.dmp However, foo.dmp contains all of the CREATE TABLE statements. I just want all of the INSERT INTO statements associated with this

Re: [sqlite] .dump/.load not workin in 3.4.0 or later for "large" rows?

--- [EMAIL PROTECTED] wrote: > I think those exceedingly rare programs that need a larger > SQL statement length limit can include their own copy of > sqlite3.c. I does not take up that much space, after all. It's easy enough to recompile with the new setting once you're aware of it. But

Re: [sqlite] .dump/.load not workin in 3.4.0 or later for "large" rows?

Joe Wilson <[EMAIL PROTECTED]> wrote: > --- [EMAIL PROTECTED] wrote: > > Yes, this does create problems for .dump/.load in the shell. > > But, as has been pointed out, you can work around it using > > a compile-time switch: > > > > gcc -DSQLITE_MAX_SQL_LENGTH=10 shell.c sqlite3.c -o

Re: [sqlite] .dump/.load not workin in 3.4.0 or later for "large" rows?

On Dec 11, 2007, at 2:10 PM, [EMAIL PROTECTED] wrote: The limits in SQLite (introduced in version 3.4.0) were added at the request of the Google Gears developers. Consider the situation that Gears and similar applications (such as Adobe AIR) are in. They have to accept generic SQL from

Re: [sqlite] .dump/.load not workin in 3.4.0 or later for "large" rows?

--- [EMAIL PROTECTED] wrote: > Yes, this does create problems for .dump/.load in the shell. > But, as has been pointed out, you can work around it using > a compile-time switch: > > gcc -DSQLITE_MAX_SQL_LENGTH=10 shell.c sqlite3.c -o sqlite3 > > I should probably modify the makefile

Re: [sqlite] .dump/.load not workin in 3.4.0 or later for "large" rows?

On Dec 11, 2007, at 2:10 PM, [EMAIL PROTECTED] wrote: You should normally not be inserting megabyte-sized blobs and strings using raw SQL. Instead, use bound parameters: sqlite3_prepare("INSERT INTO tablexyz VALUES(:blobcontent)"); sqlite3_bind_blob(pStmt, 1, pBlobContent,

Re: [sqlite] .dump/.load not workin in 3.4.0 or later for "large" rows?

Jim Correia <[EMAIL PROTECTED]> wrote: > > Is a 1MB limit on the SQL intentional? > > Per my previous message, the comment in the source disagrees with the > value. > > Also, at the default value, .dump/.load will only support rows of > about 1/2 MB (to account for hex expansion), while the

Re: [sqlite] .dump/.load not workin in 3.4.0 or later for "large" rows?

On Dec 11, 2007, at 11:03 AM, Joe Wilson wrote: If this is intentional, what is the recommended replacement for .dump/.load for large rows? You have to recompile with a large value for SQLITE_MAX_SQL_LENGTH via a compiler -D flag or other means. Monotone encountered this issue as well for

Re: [sqlite] .dump/.load not workin in 3.4.0 or later for "large" rows?

--- Jim Correia <[EMAIL PROTECTED]> wrote: > I notice that SQLite 3.4.0 and later impose hard limits on some > sizes. I'm running into a problem where a .dump/.load cycle fails on > a database with columns that have blobs which are about 2MB in size. > > Looking at the source for 3.5.3 (I

[sqlite] .dump/.load not workin in 3.4.0 or later for "large" rows?

I notice that SQLite 3.4.0 and later impose hard limits on some sizes. I'm running into a problem where a .dump/.load cycle fails on a database with columns that have blobs which are about 2MB in size. Looking at the source for 3.5.3 (I can't find a tarball of 3.4 on the web site, but I'm

[sqlite] .dump returns error 32512... sometimes

Hi everyone, I have a script that does some backup. Amongst other things, it dumps certain SQLite database, like sqlite3 /path/to/db/dname.db .dump > somefile. When I run the script manually from the command line, it works like a charm. If, however, I launch it via crontab - it fails. sqlite3

Re: [sqlite] 'dump' from the C API

Does anyone know how to do a database dump from the C API? I'm linking to sqlite3.o (the amalgamated file) and was hoping to open a database and dump the contents to an sql file. I know this can be done from the shell, but as of yet, I can't get the shell running on AIX. What version of AIX

[sqlite] 'dump' from the C API

Hello, Does anyone know how to do a database dump from the C API? I'm linking to sqlite3.o (the amalgamated file) and was hoping to open a database and dump the contents to an sql file. I know this can be done from the shell, but as of yet, I can't get the shell running on AIX. Thanks in

RE: [sqlite] Dump with where clause

line, using sqlite3.exe ? Thanks. -Original Message- From: Simon Davies [mailto:[EMAIL PROTECTED] Sent: 17 August 2007 01:41 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Dump with where clause Updating Igor's suggestion, just remove 'temp' from the line create temp table

Re: [sqlite] Dump with where clause

All I get is: > > BEGIN TRANSACTION; > COMMIT; > > > > -Original Message- > From: Dennis Cote [mailto:[EMAIL PROTECTED] > Sent: 16 August 2007 05:49 PM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Dump with where clause > > Andre du Plessis

RE: [sqlite] Dump with where clause

: 16 August 2007 05:49 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Dump with where clause Andre du Plessis wrote: > HI, how can I use .dump or something similar but specify a where clause, > I cant see that the .dump command allows this, > > Without any arguments it seems to du

Re: [sqlite] Dump with where clause

Andre du Plessis wrote: HI, how can I use .dump or something similar but specify a where clause, I cant see that the .dump command allows this, Without any arguments it seems to dump the whole db, the only argument supported is the table name, I would like to be able to do something like:

[sqlite] Dump with where clause

HI, how can I use .dump or something similar but specify a where clause, I cant see that the .dump command allows this, Without any arguments it seems to dump the whole db, the only argument supported is the table name, I would like to be able to do something like: .dump table1 where ID >

Re: [sqlite] .dump-n-reload vs. vacuum - which is better?

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

Re: [sqlite] .dump-n-reload vs. vacuum - which is better?

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

Re: [sqlite] .dump-n-reload vs. vacuum - which is better?

[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

  1   2   >