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 quotes identifie
On Jul 13, 2018, at 10:15 AM, dmp wrote:
>
> Seems .dump uses a short output of skipping the column names.
To call that a problem requires that you justify why you’d need the column
names to be specified in the INSERT statements.
If you take the .dump file as-given and just run it, the INSERT
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
http://mailinglist
Hello,
Recently in testing my GUI tool I made a comparison from the
tool's dump and SQLite's command line .dump tool.
Seems .dump uses a short output of skipping the column names.
According to some of my research for various databases I use
one of these as options for SQL dump output:
http://ajq
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.
___
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 outpu
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
-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 you
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"
intege
-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: please CC
Hey,
When creating a dump with sqlite .dump, it will not save the user_version.
Firefox is using this user_version to determine the database schema version (or
something related). When restoring a dump (but without user_version set
properly), firefox will discard all history data.
I'm not sure
11 matches
Mail list logo