[sqlite] where did my data go ? Re: Import data into a temporary table

[Larry Brasfield]

Luuk writes:
| sqlite> .import abc.csv temp.test
| Error: no such table: temp.test
|. . .
| Where did my data go (see above)?

The above command to the shell results in an attempted prepare of SQL like this,
  INSERT INTO “temp.text” VALUES …
which fails with a “no such table” complaint.  If shell.c had either not 
double-quoted the schema.tableName, or double-quoted only the tableName part, 
it would have succeeded.  It is easy to modify shell.c to eliminate the 
double-quoting if you really want to .import directly into a temp. table and 
can refrain from using goofy table names (such as would need double-quoting.)

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] .import fails CHECK constraint on valid data

[Shawn Wagner]

The check constraint is probably being evaluated (with t as a string)
before any type conversion to match the column affinity is done.

On Sun, Mar 10, 2019, 2:05 PM James K. Lowden 
wrote:

> $ sqlite3 db "create table T (t integer not null);"
> $ sqlite3 db "create table Tc (t integer not null
> check(typeof(t) = 'integer'));"
> $ echo 1 > dat
> $ sqlite3 db ".import 'dat' T"
> $ sqlite3 db ".import 'dat' Tc"
> dat:1: INSERT failed: CHECK constraint failed: Tc
> $ sqlite3 db "insert into Tc select * from T;"
> $ sqlite3 db "select * from Tc"
> 1
> $ sqlite3 db "select typeof(t) from T"
> integer
> $ sqlite3 db "select typeof(t) from Tc"
> integer
>
> Why does the .import command cause the CHECK constraint to fail, when
> an ordinary INSERT does not?
>
> --jkl
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] .import fails CHECK constraint on valid data

[James K. Lowden]

$ sqlite3 db "create table T (t integer not null);"
$ sqlite3 db "create table Tc (t integer not null 
check(typeof(t) = 'integer'));" 
$ echo 1 > dat
$ sqlite3 db ".import 'dat' T"
$ sqlite3 db ".import 'dat' Tc"
dat:1: INSERT failed: CHECK constraint failed: Tc
$ sqlite3 db "insert into Tc select * from T;"
$ sqlite3 db "select * from Tc"
1
$ sqlite3 db "select typeof(t) from T"
integer
$ sqlite3 db "select typeof(t) from Tc"
integer

Why does the .import command cause the CHECK constraint to fail, when
an ordinary INSERT does not?  

--jkl
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] missing SQLITE_DEFAULT_TEMP_CACHE_SIZE

[Joshua Thomas Wise]

Hello,

The documentation here 
 
(https://www.sqlite.org/tempfiles.html#other_temporary_file_optimizations 
) 
mentions that temporary tables and indexes each use their own page cache, which 
is sized by the SQLITE_DEFAULT_TEMP_CACHE_SIZE compile-time option. However, I 
can’t find any mention of that identifier anywhere in the sqlite3 source code. 
Additionally, that documentation conflicts with this documentation 
 
(https://www.sqlite.org/pragma.html#pragma_cache_size 
) which states that the 
TEMP database always has a cache size of 0. What’s the true story behind page 
caches of temporary files, and how can I control their sizes?
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users