[sqlite] User input checking
I'm planning to allow users to make database queries through a web page. I'm thinking of letting the user provide the string that goes between SELECT and FROM using the sqlite3 command tool, but what kind of input checking is then needed? Obviously, I need to check that the input doesn't contain any semicolons, otherwise the user could enter something like "; DROP big_table;". But is there anything else that needs checking? I only want to make sure that the user can't change anything. If the query is too big and will take forever, that's fine for now. xkcd comes to mind: http://xkcd.com/327/ :) -- Steinar ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] VACUUMing large DBs
Very nice! Thanks ! But then - can you turn journaling off and then run a VACUUM and have it run as a 2-step instead of a 3-step? On Thu, Mar 22, 2012 at 3:25 PM, Petite Abeille wrote: > > On Mar 22, 2012, at 11:19 PM, Udi Karni wrote: > > > Is there a way to run NOLOGGING in SQlite syntax - which means that if > > something in the destination table/DB fails - you are prepared to just > drop > > it and start over? > > PRAGMA journal_mode=off > > http://sqlite.org/pragma.html#pragma_journal_mode > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] VACUUMing large DBs
On Mar 22, 2012, at 11:19 PM, Udi Karni wrote: > Is there a way to run NOLOGGING in SQlite syntax - which means that if > something in the destination table/DB fails - you are prepared to just drop > it and start over? PRAGMA journal_mode=off http://sqlite.org/pragma.html#pragma_journal_mode ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] VACUUMing large DBs
For the time being - I have been avoiding the VACUUM of very large DBs by creating a new iteration of the table/DB for each transformation instead of using UPDATE/DELETE (given that I only have 1 table per DB) - (1) create new DB_V2 / Table_V2 (2) attach DB_V1 / Table_V1 (3) insert into Table_V2 select (column list with transformations) from Table_V1 (4) drop DB_V1 If there are too many transformations - I just do it in a few iterations. By using 2 seperate disks for the 2 DBs/tables - one only reads - the other only writes - rows don't grow/shrink - and especially if both disks are SSDs - this works quite fast and no need to VACUUM the final version. What would make it even better would be the possibility of using CREATE TABLE X NOLOGGING AS SELECT ... FROM Y; Is there a way to run NOLOGGING in SQlite syntax - which means that if something in the destination table/DB fails - you are prepared to just drop it and start over? Thanks ! On Thu, Mar 22, 2012 at 3:06 PM, Scott Hess wrote: > On Tue, Mar 20, 2012 at 8:25 PM, Jay A. Kreibich wrote: > > On Tue, Mar 20, 2012 at 01:59:59PM -0700, Udi Karni scratched on the > wall: > >> Is there a way to go directory from "original" to "journal/final" - > >> skipping the creation of the Temp version? > > > > No, it requires all three copies. > <...> > > Almost exactly two years ago I proposed a "VACUUM TO " > > version of the command that did the first copy and then quit. Rather > > than building an optimized temp copy, VACUUM TO would copy the > > current database to an optimized named file (rather than a temp file), > > and then skip the copy-back stage. This would allow a system admin > > to shut down all database users, VACUUM the database, swap files, > > and finally restart everything. The process would require more > > manual work, but would only require 2x the drive space, rather than > > 3x. Nobody spoke up about the idea, however. > > I think you could manage 2x-the-drive-space without shutdown by > writing a read-only VFS which treated the pages in the journal as its > backing store, faulting missed through to the main file. Then you > could VACUUM from the database-in-the-journal to the > database-in-the-database. In case of failure, the journal rolls > things back like you'd expect. > > I _think_ this would work. > > -scott > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] VACUUMing large DBs
On Tue, Mar 20, 2012 at 8:25 PM, Jay A. Kreibich wrote: > On Tue, Mar 20, 2012 at 01:59:59PM -0700, Udi Karni scratched on the wall: >> Is there a way to go directory from "original" to "journal/final" - >> skipping the creation of the Temp version? > > No, it requires all three copies. <...> > Almost exactly two years ago I proposed a "VACUUM TO " > version of the command that did the first copy and then quit. Rather > than building an optimized temp copy, VACUUM TO would copy the > current database to an optimized named file (rather than a temp file), > and then skip the copy-back stage. This would allow a system admin > to shut down all database users, VACUUM the database, swap files, > and finally restart everything. The process would require more > manual work, but would only require 2x the drive space, rather than > 3x. Nobody spoke up about the idea, however. I think you could manage 2x-the-drive-space without shutdown by writing a read-only VFS which treated the pages in the journal as its backing store, faulting missed through to the main file. Then you could VACUUM from the database-in-the-journal to the database-in-the-database. In case of failure, the journal rolls things back like you'd expect. I _think_ this would work. -scott ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] select null values in python
On 22 March, Jean-Denis wrote: On 22 mars 2012, at 17:26, Igor Tandetnik wrote: > On 3/22/2012 12:18 PM, Jean-Denis MUYS wrote: >> >> On 22 mars 2012, at 16:41, Igor Tandetnik wrote: >> >>> On 3/22/2012 11:32 AM, Fabio Spadaro wrote: If I want to run a query like "select * from tablename where field1 = Null" >>> >>> select * from tablename where field1 is null; >>> >>> NULL is never equal any value, not even another NULL. >>> -- >>> Igor Tandetnik >>> >> >> Welcome to Igor's style. He never answers the question you don't ask :-) >> >> I have come to learn and appreciate his socratic style. Thanks Igor. >> >> In the meantime, you might be interested in something like >> >> select * from tablename where field1 IS Null > > I did show this very example, except lacking the whitespace in front and differing in capitalization. I assume you feel those distinct characteristics render your example more interesting than mine. > -- > Igor Tandetnik Well, my apology. I didn't read your example carefully enough. Shame on me. Let me retract my answer (except my praise for your Socratic style, which I will not retract even if it doesn't quite apply here). Jean-Denis (I doubt Igor felt damaged or slighted. Shame is hardly due. He was just having some gentle fun.) I just wanted to chime in with appreciation for Igor's contributions, especially that he often *does* answer the question not asked when that is more germane than simply answering the OP's question. I often find his replies instructive. -- Larry Brasfield ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] select null values in python
On 22 mars 2012, at 17:26, Igor Tandetnik wrote: > On 3/22/2012 12:18 PM, Jean-Denis MUYS wrote: >> >> On 22 mars 2012, at 16:41, Igor Tandetnik wrote: >> >>> On 3/22/2012 11:32 AM, Fabio Spadaro wrote: If I want to run a query like "select * from tablename where field1 = Null" >>> >>> select * from tablename where field1 is null; >>> >>> NULL is never equal any value, not even another NULL. >>> -- >>> Igor Tandetnik >>> >> >> Welcome to Igor's style. He never answers the question you don't ask :-) >> >> I have come to learn and appreciate his socratic style. Thanks Igor. >> >> In the meantime, you might be interested in something like >> >> select * from tablename where field1 IS Null > > I did show this very example, except lacking the whitespace in front and > differing in capitalization. I assume you feel those distinct characteristics > render your example more interesting than mine. > -- > Igor Tandetnik Well, my apology. I didn't read your example carefully enough. Shame on me. Let me retract my answer (except my praise for your Socratic style, which I will not retract even if it doesn't quite apply here). Jean-Denis ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] select null values in python
> I did show this very example, except lacking the whitespace in front > and differing in capitalization. I assume you feel those distinct > characteristics render your example more interesting than mine. Or mine, which was sent minutes before Igor's. Hmph. ;) ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] select null values in python
On 3/22/2012 12:18 PM, Jean-Denis MUYS wrote: On 22 mars 2012, at 16:41, Igor Tandetnik wrote: On 3/22/2012 11:32 AM, Fabio Spadaro wrote: If I want to run a query like "select * from tablename where field1 = Null" select * from tablename where field1 is null; NULL is never equal any value, not even another NULL. -- Igor Tandetnik Welcome to Igor's style. He never answers the question you don't ask :-) I have come to learn and appreciate his socratic style. Thanks Igor. In the meantime, you might be interested in something like select * from tablename where field1 IS Null I did show this very example, except lacking the whitespace in front and differing in capitalization. I assume you feel those distinct characteristics render your example more interesting than mine. -- Igor Tandetnik ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] select null values in python
On 22 mars 2012, at 16:41, Igor Tandetnik wrote: > On 3/22/2012 11:32 AM, Fabio Spadaro wrote: >> If I want to run a query like "select * from tablename where field1 = Null" > > select * from tablename where field1 is null; > > NULL is never equal any value, not even another NULL. > -- > Igor Tandetnik > Welcome to Igor's style. He never answers the question you don't ask :-) I have come to learn and appreciate his socratic style. Thanks Igor. In the meantime, you might be interested in something like select * from tablename where field1 IS Null Jean-Denis ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] select null values in python
On 22 Mar 2012, at 3:41pm, Igor Tandetnik wrote: > On 3/22/2012 11:32 AM, Fabio Spadaro wrote: >> If I want to run a query like "select * from tablename where field1 = Null" > > select * from tablename where field1 is null; > > NULL is never equal any value, not even another NULL. So experiment with SELECT * FROM tablename WHERE typeof(field1) = "null" ? Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] select null values in python
On 3/22/2012 11:32 AM, Fabio Spadaro wrote: If I want to run a query like "select * from tablename where field1 = Null" select * from tablename where field1 is null; NULL is never equal any value, not even another NULL. -- Igor Tandetnik ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] select null values in python
select * from tablename where field1 IS Null > -Original Message- > From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- > boun...@sqlite.org] On Behalf Of Fabio Spadaro > Sent: Thursday, March 22, 2012 11:33 AM > To: General Discussion of SQLite Database > Subject: [sqlite] select null values in python > > Using sqlite3 python and I have a problem running a query. > My table has null values. Now if I do a 'select * from tablename' > returns to me as the result: > [(datetime.date (2012, 3, 22), buffer ptr 0x03774B90, > 0x03774B58> at size 0, None, None, None, None, None, None)] > As you can see there are null values that in python are None type. > If I want to run a query like "select * from tablename where field1 = > Null" > returns no results and even if I run "select * from tablename where > field1 = None" None because there is not in Sqlite. You should use an > adapter or something? > > -- > Fabio Spadaro > > Try Sqlite Root a GUI Admin Tools for manage Sqlite Database: > www.sqliteroot.com > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] version 3.7.3 on linux, commands do not respond
Glubs! Are yout right. At some point I misspelled the name of the database by invoking sqlite and even if you do nothing it writes an empty file. Thank you and excuse me for that so silly question. Conxita. El 22/03/2012 10:27, Simon Davies escribió: 2012/3/22 Conxita Marín: It has to be something more complexof course, I tried the same database in Debian Lenny + Sqlite3 3.5.9 and it works perfectly: conxita@my_other_linux# sqlite3 backup_bd SQLite version 3.5.9 Enter ".help" for instructions sqlite> .tables android_metadata dbversion prefs Compare from your original post and above: conxita@mylinux$: sqlite3 backup.bd SQLite version 3.7.3 conxita@my_other_linux# sqlite3 backup_bd SQLite version 3.5.9 We can't tell if they are really the same underlying data, but the names are different. Do you change the db name when moving between machines? Any other ideas? Conxita Regards, Simon ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] select null values in python
Using sqlite3 python and I have a problem running a query. My table has null values. Now if I do a 'select * from tablename' returns to me as the result: [(datetime.date (2012, 3, 22), buffer ptr at size 0, None, None, None, None, None, None)] As you can see there are null values that in python are None type. If I want to run a query like "select * from tablename where field1 = Null" returns no results and even if I run "select * from tablename where field1 = None" None because there is not in Sqlite. You should use an adapter or something? -- Fabio Spadaro Try Sqlite Root a GUI Admin Tools for manage Sqlite Database: www.sqliteroot.com ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 64-bit Windows Command Shell
There is a natural 5th extrapolation: 5) Could sqlite3 take advantage of multiple cpu's by parsing a single task into one thread per cpu and segment data to be worked by each thread? Big league stuff. But I don't think sqlite3 is meant to compete in that market. It already exceeds expectations in its current market. dvn On Wed, Mar 21, 2012 at 6:57 PM, Udi Karni wrote: > Frankly I don't know if a 64-bit version and Big RAM would make a > difference and if so - up to what point. With SQLite being a single process > - assigned for the most part to a single CPU - even if everything was done > in RAM - there is a limit to what 1 CPU can do. > > I am just noticing anecdotally that SQlite uses cache and dealing with > tables of a few hundred MB or less doesn't seem to generate IO. Also - when > there is IO - it often comes from the swap file (under Windows 7). > > So the questions are - > > (1) how much RAM is the point of diminishing returns on 32-bit > (2) is there value to going 64-bit > (3) if there was a 64-bit version - would it use more RAM more effectively? > (4) as a fallback - let's say the 32-bit version and 4GB are as good as you > can pretty much expect. Would getting a server with 4 CPUs and 16GB (a > high-end home-version PC) - reasonably enable me to run 3-4 SQLite jobs > concurrently? In other words - no great speed improvement per job - but in > aggregate more work could get done? > > Thanks ! > > On Wed, Mar 21, 2012 at 12:26 PM, Roger Binns > wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 21/03/12 11:09, Black, Michael (IS) wrote: > > > Cache is the primary (and obvious) thing I can think of. > > > > With a 32 bit compilation you'll be able to bump it up to about 2GB. > > However by that point you will long have passed diminishing returns and > > can just let the OS do its own caching. > > > > Roger > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.11 (GNU/Linux) > > > > iEYEARECAAYFAk9qK2IACgkQmOOfHg372QQVdwCfbJTAzhCPR4ARPxhYHewLvvcT > > 4lYAoI4QFXFfxILtsQGxVWm8BRM/mbIX > > =e0aW > > -END PGP SIGNATURE- > > ___ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Can't get foreign keys to work
Thank you. I see now that it was in the documentation, but I just didn't see it. On 22.3.2012 14:48, Richard Hipp wrote: PRAGMA foreign_keys=ON; ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Can't get foreign keys to work
On Thu, Mar 22, 2012 at 8:46 AM, Marko Mikkonen wrote:
> Hi,
>
> I have two tables like this:
>
> CREATE TABLE IF NOT EXISTS folders (name TEXT NOT NULL ON CONFLICT
> ROLLBACK, parent INTEGER REFERENCES folders (ROWID) ON DELETE CASCADE);
>
> CREATE TABLE IF NOT EXISTS documents (document TEXT NOT NULL ON CONFLICT
> ROLLBACK, folder_id INTEGER REFERENCES folders (ROWID) ON DELETE CASCADE,
> name TEXT NOT NULL ON CONFLICT ROLLBACK);
>
> If I try to add a rows to a fresh database like this:
>
> INSERT INTO folders (parent, name) VALUES (3,'New Folder');
> INSERT INTO documents (document, folder_id, name) values ('some
> text',3,'the name');
>
> I can do it eventhough it violates the foreign key constraints (ROWID of
> the row in folders table is 1). What's wrong with my table definitions? My
> sqlite3.exe's version is 3.7.11 and according to the documentation the
> foreign key constraints should be enforced.
>
For backwards compatibility to legacy versions of SQLite, foreign key
constraints are disabled by default. You have to manually turn foreign key
enforcement on using:
PRAGMA foreign_keys=ON;
>
> -Marko
> __**_
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>
--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Can't get foreign keys to work
Hi,
I have two tables like this:
CREATE TABLE IF NOT EXISTS folders (name TEXT NOT NULL ON CONFLICT
ROLLBACK, parent INTEGER REFERENCES folders (ROWID) ON DELETE CASCADE);
CREATE TABLE IF NOT EXISTS documents (document TEXT NOT NULL ON CONFLICT
ROLLBACK, folder_id INTEGER REFERENCES folders (ROWID) ON DELETE
CASCADE, name TEXT NOT NULL ON CONFLICT ROLLBACK);
If I try to add a rows to a fresh database like this:
INSERT INTO folders (parent, name) VALUES (3,'New Folder');
INSERT INTO documents (document, folder_id, name) values ('some
text',3,'the name');
I can do it eventhough it violates the foreign key constraints (ROWID of
the row in folders table is 1). What's wrong with my table definitions?
My sqlite3.exe's version is 3.7.11 and according to the documentation
the foreign key constraints should be enforced.
-Marko
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Shell .dump incorrectly quotes the table name in 3.7.11
Shell .dump command produces incorrect output when using keyword as a
table name.
Example:
SQLite version 3.7.11 2012-03-20 11:35:50
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> CREATE TABLE "table" ("column" TEXT);
sqlite> INSERT INTO "table" VALUES('value');
sqlite> .dump
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE "table" ("column" TEXT);
INSERT INTO table VALUES('value');
COMMIT;
Reading this dump will cause a syntax error:
sqlite> .read dump.sql
Error: near line 4: near "table": syntax error
The table name in the insert statement is not properly quoted.
I think that this behavior is related to the change (3) at
http://www.sqlite.org/src/info/e6eea8d50d
Thanks
Martin
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] version 3.7.3 on linux, commands do not respond
2012/3/22 Conxita Marín : > It has to be something more complexof course, I tried the same database in > Debian Lenny + Sqlite3 3.5.9 and it works perfectly: > > conxita@my_other_linux# sqlite3 backup_bd > SQLite version 3.5.9 > Enter ".help" for instructions > sqlite> .tables > android_metadata dbversion prefs Compare from your original post and above: conxita@mylinux$: sqlite3 backup.bd SQLite version 3.7.3 conxita@my_other_linux# sqlite3 backup_bd SQLite version 3.5.9 We can't tell if they are really the same underlying data, but the names are different. Do you change the db name when moving between machines? > > Any other ideas? > > Conxita > Regards, Simon ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Join-source issue when using sub '(' join-source ')'
Hi,
You're wrong.
I think I've found the bug.
It is a parser issue.
According to their definition
(http://sqlite.org/syntaxdiagrams.html#single-source) , Join sources (named
single-source) are either :
* a table or view with an optional alias and/or with an optional index
* a sub query with an optional alias
* a sub join (with no alias)
In SQLite parser.y source code we can find on line 496 the grammar rule
handling those three cases (in the same order)
...
seltablist(A) ::= stl_prefix(X) nm(Y) dbnm(D) as(Z) indexed_opt(I) on_opt(N)
using_opt(U). {
A = sqlite3SrcListAppendFromTerm(pParse,X,&Y,&D,&Z,0,N,U);
sqlite3SrcListIndexedBy(pParse, A, &I);
}
seltablist(A) ::= stl_prefix(X) LP select(S) RP
as(Z) on_opt(N) using_opt(U). {
A = sqlite3SrcListAppendFromTerm(pParse,X,0,0,&Z,S,N,U);
}
seltablist(A) ::= stl_prefix(X) LP seltablist(F) RP
as(Z) on_opt(N) using_opt(U). {
if( X==0 && Z.n==0 && N==0 && U==0 ){
A = F;
}else{
Select *pSubquery;
sqlite3SrcListShiftJoinType(F);
pSubquery = sqlite3SelectNew(pParse,0,F,0,0,0,0,0,0,0);
A = sqlite3SrcListAppendFromTerm(pParse,X,0,0,&Z,pSubquery,N,U);
}
}
...
Case 1 and 2 are handled properly but as you can see the third definition (wich
should deal with sub joins) contains mistakes :
#1 : It allows an as clause after the parenthesis
#2 : on the right of a join operator (else { ... }) it generates a
subquery instead of merging F (which is a seltabList, not a sub query) with X
into A.
Do you still think there is no issue here ?
I wish I could propose a fix but I have no skills in C/yacc.
Hope this will help anyway.
Thanks
-Message d'origine-
De : sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org]
De la part de Nico Williams
Envoyé : lundi 19 mars 2012 16:10
À : General Discussion of SQLite Database
Objet : Re: [sqlite] Join-source issue when using sub '(' join-source ')'
On Mon, Mar 19, 2012 at 10:02 AM, TAUZIN Mathieu wrote:
> Thanks,
>
> This syntax works but it is not documented... it looks like a short hand for
> a subquery, interesting !.
Join sources are like sub-queries. Look at the syntax.
A sub-select specified in the join-source following the FROM clause in a simple
SELECT statement is handled as if it was a table containing the data returned
by executing the sub-select statement. The docs could perhaps be clearer about
this. This sentence:
"A sub-select specified in the join-source following the FROM clause in a
simple SELECT statement is handled as if it was a table containing the data
returned by executing the sub-select statement. "
does hint at this, but maybe that's just because I think of as
a sort of sub-select.
Nico
--
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] version 3.7.3 on linux, commands do not respond
It has to be something more complexof course, I tried the same database in Debian Lenny + Sqlite3 3.5.9 and it works perfectly: conxita@my_other_linux# sqlite3 backup_bd SQLite version 3.5.9 Enter ".help" for instructions sqlite> .tables android_metadata dbversion prefs Any other ideas? Conxita El 21/03/2012 13:26, Igor Tandetnik escribió: Conxita Marín wrote: I'm in my new Linux box, Linux Debian Squeeze, I installed the version 3.7.3.of sqlite3, that comes in the repositories that I use. Any command respond, no error, nothing conxita@mylinux$: sqlite3 backup.bd SQLite version 3.7.3 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> .tables sqlite> This just means the database in backup.bd doesn't contain any tables. Did you perhaps mean backup.db ? ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
