[sqlite] Virtual tables and OR clause
Hi Folks, Using virtual tables the WHERE clause is broken up and sent to the best index function to determine the best index. Then the filter function is called to perform the actual work. I've noticed that the SQLITE engine seems to process OR clauses outside of the virtual table process, while AND clauses are provided to the filter function to use. How can we get the OR clauses sent to the filter function where we can make use of that information? Using SQLITE 3.6.18. Thanks, -Allan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Detecting storage class from C
I guess I'm confused as to why sqlite3_column_type() would not work? It works for me on queries and I get back either SQLITE_INTEGER, SQLITE_FLOAT, or SQLITE3_TEXT. While I know the types could be coerced to something else, at least it is an answer of what you originally intended the column to be. Since your generic wrapper interface is strongly typed, I would suspect that the values would not be coerced into strange things and maps nicely to one of the above types. -Allan -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- boun...@sqlite.org] On Behalf Of Jay A. Kreibich Sent: Wednesday, September 08, 2010 3:37 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Detecting storage class from C On Wed, Sep 08, 2010 at 10:01:48PM +0100, Andrew Wood scratched on the wall: Because I'm writing glue code between the SQLite API and a higher level library which provides a standard API across several DBMSs. In other DBMSs even if a field contains null you can still ask the API what type it 'should' have been if something *had* been put in it. Without this ability, I cant make SQLite work with the library. I don't understand the reasoning for designing SQLite weakly typed like this, it just seems bizarre. SQLite is not weakly typed. Each value has a very specific and strongly enforced type. It just happens that type assignment happens at the value level, rather than the column level. When I first came to SQLite from the client/server RDBMS world, I was somewhat shocked as well. But in the end, it really doesn't make much of a difference. Like most other languages, all forms of SQL do a significant amount of type coercion. Opening up that domain to something larger than what a traditional programmer considers a type doesn't really change anything. Does it really matter that -3 5.35667 'abc' ? As long as you have a solid ordering and conversion rules, there are rarely surprises. And if someone really cares, they can add CHECK constraints-- which they should be doing anyways if they're that paranoid about type-domain checking. Simply limiting a value to an integer (or whatever) is no more or less safe unless you further limit things to a task-specific sub-domain of that type. I also have to say that handling NULLs as a value-less type is a very clean and handy model. -j -- Jay A. Kreibich J A Y @ K R E I B I.C H Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable. -- Angela Johnson ___ 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] Question about lemon
Hi Andy, Instead of adding the definition cmd ::= set_item. have you thought about defining the acceptable alternatives to SET? For instance, set ::= SET. set ::= . cmd ::= set set_list. The way you specified it on cmd I think created your problem. By adding another level it may give the parser enough room to work the way you wanted. I haven't tried your specific grammar, but I had a similar issue and this seemed to work for me. Regards, -Allan -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- boun...@sqlite.org] On Behalf Of Andy Gibbs Sent: Thursday, April 01, 2010 8:04 AM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Question about lemon Hi, sorry to bump this thread, but I thought I'd just try once more to see whether anybody might have some insight on the problem I'm having with Lemon, as detailed in the original post below. I'm sure posts that languish on this mailing list quickly get snowed under! I appreciate its not an Sqlite question, but I don't know where else to post questions about Lemon. Thanks!!! Andy - Original Message - From: Andy Gibbs Sent: Wednesday, March 10, 2010 10:54 AM Subject: Question about lemon Hello, Is it alright to ask a quick question about the lemon parser in this mailing list, or is there a dedicated one which I should post this to instead? I'm using lemon to create a parser for a simple c/basic-like grammar, and have among other rules, the following defined (I've trimmed it down to what I believe are the important bits for this email, so hopefully its all there): cmd ::= WHILE expr DO cmd_list END. cmd ::= CASE case_list END. cmd ::= SET set_list. cmd_list ::= cmd_list cmd SEMI. cmd_list ::= cmd SEMI. case_list ::= case_list case_cond cmd_list. case_list ::= case_cond cmd_list. case_cond ::= WHEN expr THEN. case_cond ::= ELSE. set_list ::= set_list COMMA set_item. set_list ::= set_item. set_item ::= ID ASSIGN expr. This in itself works correctly, parsing such code as... SET a := 0; WHILE a 12 DO some_other_statement; CASE WHEN a = 5 THEN another_statement; yet_another_statement; WHEN a = 11 THEN do_something; END; SET a := a+1; END; However, I would like to be able to add the rule: cmd ::= set_item. so that the SET keyword becomes optional in the above code (i.e. so that I can write a := 0; instead of SET a := 0;). When I do this however, the parser then fails to parse CASE constructs. I believe I know where the problem lies: I am using the %fallback directive which includes a number of keywords that fallback to ID, and in this list is the END keyword. Ideally I would like to leave the fallback list as it is, if possible, and in fact I'd much rather not add the additional rule than change this! What interests me is that the WHILE construct still parses correctly. An output from the parser trace gives the following: ... Stack: WHILE expr DO cmd SEMI Input END Reduce [cmd_list ::= cmd SEMI]. Shift 8 Stack: WHILE expr DO cmd_list END Input SEMI Reduce [cmd ::= WHILE expr DO cmd_list END]. Shift 410 Stack: cmd Shift 515 Stack: cmd SEMI ... But with the CASE construct, I get: ... Stack: CASE case_list case_cond cmd SEMI Input END Reduce [cmd_list ::= cmd SEMI]. Shift 10 Stack: CASE case_list case_cond cmd_list FALLBACK END = ID Shift 713 Stack: CASE case_list case_cond cmd_list END Input SEMI Syntax error! My understanding is that it simply isn't able to reduce CASE case_list case_cond cmd_list END to CASE case_list END and then cmd and so instead takes END to be the left-hand-side of the set_item rule as a continuation of cmd_list, gets a semi-colon as the next character which according to that rule would be a syntax error. My question -- sorry this is such a long post -- is, what is it about the grammar for WHILE which allows it to work, and CASE that causes it to fail? It is because there is an extra list level in the grammar (case_list - cmd_list, instead of just cmd_list)? Is there any way I can change the grammar to do what I hope to do, or is this a limitation of lemon? I've tried adding a rule cmd ::= CASE case_cond cmd_list END but this causes a parsing conflict error message in lemon. I've also had a look into the lemon source code to see if I could find an answer there, but I'm afraid its engineering brilliance is beyond me! Thank you very much for any help that can be offered. Andy ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] why is underscore like dash?
Perhaps because underscore is considered to be a wild-card search character.
Take a look at: http://sqlite.org/lang_expr.html#like
If you want to match underscore literally, use an optional escape character
clause and escape the underscore.
-Allan
-Original Message-
From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
boun...@sqlite.org] On Behalf Of Wilson, Ronald
Sent: Tuesday, March 02, 2010 10:41 AM
To: General Discussion of SQLite Database
Subject: [sqlite] why is underscore like dash?
This test was performed on Windows XP:
PS C:\Documents and Settings\ma088024 sqlite3
SQLite version 3.6.22
Enter .help for instructions
Enter SQL statements terminated with a ;
sqlite create table test (text);
sqlite insert into test values('_');
sqlite insert into test values('-');
sqlite select * from test where text like '-';
-
sqlite select * from test where text like '_';
_
-
sqlite .quit
RW
Ron Wilson, Engineering Project Lead
(o) 434.455.6453, (m) 434.851.1612, www.harris.com
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ambiguous column name
The TK_ALL (*) expansion explicitly removes duplicate columns from tables joined using a natural join or those found in a using statement. For those interested in the code, check out selectExpander() +165 through +178. So while the * expansion only shows column a, it happens to be showing column t1.a and removing the rest. Igor's comments are correct that there are three columns and if you specify just a, the parser doesn't know which one. -Allan -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- boun...@sqlite.org] On Behalf Of Pavel Ivanov Sent: Wednesday, December 23, 2009 9:24 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] ambiguous column name You have three distinct columns here - t1.a, t2.a and t3.a. With left joins, it's possible for some but not all of them to be null, so it matters which one you select. Even with inner joins, it may matter which column you pick. E.g., in SQLite it's possible that a=b but typeof(a) != typeof(b) I believe OP's point here (which I can agree with) is when he executes select * ... he gets only one column (which one is it btw?). So it's quite reasonable to assume that if he puts the name of this column instead of asterisk he should get the same result. But he doesn't get it. Pavel On Wed, Dec 23, 2009 at 11:09 AM, Igor Tandetnik itandet...@mvps.org wrote: Wiktor Adamski bardzotajneko...@interia.pl wrote: There's no reason for following error: SQLite version 3.6.21 Enter .help for instructions Enter SQL statements terminated with a ; sqlite .headers ON sqlite create table t1(a int); sqlite create table t2(a int); sqlite create table t3(a int); sqlite insert into t1 values(1); sqlite select * from t1 left join t2 using(a) left join t3 using(a); a 1 sqlite select a from t1 left join t2 using(a) left join t3 using(a); Error: ambiguous column name: a You have three distinct columns here - t1.a, t2.a and t3.a. With left joins, it's possible for some but not all of them to be null, so it matters which one you select. Even with inner joins, it may matter which column you pick. E.g., in SQLite it's possible that a=b but typeof(a) != typeof(b) Igor Tandetnik ___ 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] ambiguous column name
Forgot to mention, compare the previous query to: select * from t1 left join t2 on t1.a = t2.a left join t3 on t1.a = t3.a; a|a|a 1|| -Allan -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- boun...@sqlite.org] On Behalf Of Schrum, Allan Sent: Wednesday, December 23, 2009 9:45 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] ambiguous column name The TK_ALL (*) expansion explicitly removes duplicate columns from tables joined using a natural join or those found in a using statement. For those interested in the code, check out selectExpander() +165 through +178. So while the * expansion only shows column a, it happens to be showing column t1.a and removing the rest. Igor's comments are correct that there are three columns and if you specify just a, the parser doesn't know which one. -Allan -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- boun...@sqlite.org] On Behalf Of Pavel Ivanov Sent: Wednesday, December 23, 2009 9:24 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] ambiguous column name You have three distinct columns here - t1.a, t2.a and t3.a. With left joins, it's possible for some but not all of them to be null, so it matters which one you select. Even with inner joins, it may matter which column you pick. E.g., in SQLite it's possible that a=b but typeof(a) != typeof(b) I believe OP's point here (which I can agree with) is when he executes select * ... he gets only one column (which one is it btw?). So it's quite reasonable to assume that if he puts the name of this column instead of asterisk he should get the same result. But he doesn't get it. Pavel On Wed, Dec 23, 2009 at 11:09 AM, Igor Tandetnik itandet...@mvps.org wrote: Wiktor Adamski bardzotajneko...@interia.pl wrote: There's no reason for following error: SQLite version 3.6.21 Enter .help for instructions Enter SQL statements terminated with a ; sqlite .headers ON sqlite create table t1(a int); sqlite create table t2(a int); sqlite create table t3(a int); sqlite insert into t1 values(1); sqlite select * from t1 left join t2 using(a) left join t3 using(a); a 1 sqlite select a from t1 left join t2 using(a) left join t3 using(a); Error: ambiguous column name: a You have three distinct columns here - t1.a, t2.a and t3.a. With left joins, it's possible for some but not all of them to be null, so it matters which one you select. Even with inner joins, it may matter which column you pick. E.g., in SQLite it's possible that a=b but typeof(a) != typeof(b) Igor Tandetnik ___ 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 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bug: Problem with left-outer join and virtual tables. Version 3.6.18 and trunk
Bump. One bump limit met :-)
Didn't know if this got lost in the holiday rush, but the bug remains. I have a
work-around (see below) that does work, but didn't know if there was a better
solution.
Regards,
-Allan
-Original Message-
From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
boun...@sqlite.org] On Behalf Of Schrum, Allan
Sent: Monday, November 23, 2009 11:29 AM
To: General Discussion of SQLite Database
Subject: [sqlite] Bug: Problem with left-outer join and virtual tables.
Version 3.6.18 and trunk
Hi Folks,
I have a virtual table implementation currently based upon 3.6.18
sources. I have found a bug in the way left outer joins are implemented
in SQLITE3 that causes bad results to occur. The short description of
the problem is that the temporary registers setup to fetch data from
the virtual tables overwrite the register used to store a value as part
of the loop. By that I mean an inner loop overwrites a value that is
expected to be there when used by the outer loop. As such, the result
set is not as expected.
The virtual table setup can be emulated with the following SQL:
create table atab(id int, mask text) ;
create table btab(mask text, bid int) ;
create table ctab(bid int, desc text) ;
insert into atab values (1, '1234') ;
insert into atab values (2, '2345') ;
insert into btab values ('1234', 1) ;
insert into btab values ('1234', 2) ;
insert into btab values ('1234', 3) ;
insert into btab values ('1234', 7) ;
insert into ctab values ( 1, 'Text for 1') ;
insert into ctab values ( 2, 'Text for 2') ;
insert into ctab values ( 3, 'Text for 3') ;
select a.id, a.mask, b.mask, b.bid, c.bid, c.desc
from atab as a
left outer join btab as b
on a.mask = b.mask
left outer join ctab as c
on b.bid = c.bid
where
a.id = 1 ;
The following is the explain of the query as a virtual table
implementation. The names have been corrected to emulate the SQL
above, and the column numbers are obviously a bit different than those
found above, but the problem is demonstrated:
addr opcode p1p2p3p4 p5
comment
- - -- -
0 Trace 0 0 000
(null)
1 Integer3 1 000
(null)
2 Goto 0 50000
(null)
3 VOpen 0 0 0 vtab:8224638:8101800 00 atab
4 VOpen 1 0 0 vtab:81F90E0:8101800 00 btab
5 VOpen 2 0 0 vtab:81E71C0:8101800 00 ctab
6 SCopy 1 4 000
(null)
7 Integer1 2 000
(null)
8 Integer1 3 000
(null)
9 VFilter0 46200
(null)
10VColumn0 0 600
atab.id
11Ne 1 456 collseq(BINARY)6c
(null)
12Integer0 8 000 init
LEFT JOIN no-match flag
13VColumn0 3 400
atab.mask
14Integer1 2 000
(null)
15Integer1 3 000
(null)
16VFilter1 42200
(null)
17VColumn1 0 700
btab.mask
18Ne 7 414 collseq(BINARY)6a
(null)
19Integer1 8 000
record LEFT JOIN hit
20Integer0 9 000 init
LEFT JOIN no-match flag
21Integer174 000
(null)
22VColumn1 1 500
btab.bid
23Integer2 2 000
(null)
24Integer2 3 000
(null)
25VFilter2 38200
(null)
26VColumn2 0 700
ctab.bid
27Integer176 000
(null)
28Ne 6 377 collseq(BINARY)6c
(null)
29VColumn2 1 600
ctab.bid
30Ne 6 375 collseq(BINARY)6b
(null)
31Integer1 9 000
record LEFT JOIN hit
32VColumn0 3 10 00
atab.mask
33VColumn1 1 11 00
btab.bid
34VColumn2 1 12 00
ctab.bid
35VColumn2 2 13 00
ctab.desc
36
Re: [sqlite] Error: file is encrypted or is not a database
-Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- boun...@sqlite.org] On Behalf Of Dmitri Priimak Sent: Wednesday, November 25, 2009 11:39 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] Error: file is encrypted or is not a database Simon Slavin wrote: On 25 Nov 2009, at 6:19pm, Dmitri Priimak wrote: Simon Slavin wrote: On 25 Nov 2009, at 6:09pm, Dmitri Priimak wrote: 000 6166 6c69 6465 7420 206f 706f 6e65 6420 010 7461 6261 7361 2065 7274 6e61 6173 7463 020 6f69 206e 3632 3a20 6620 6c69 2065 7369 030 6520 636e 7972 7470 6465 6f20 2072 7369 040 6e20 746f 6120 6420 7461 6261 7361 2065 050 684f 6d20 2e79 5720 2065 6166 6c69 6465 060 7420 206f 6f72 6c6c 6162 6b63 7420 6172 That is the text aflidet oponed tabasa ertnaastcoi n62: f li esie cnyrtpdeo rsin toa d tabasa ehOm .yW eaflidet oorllabkct ar You are writing text over your database file. I do not remember doing it. Okay, rather than you yourself, I mean something in your computer. Whatever that text is, it's not a SQLite database file and it's not even a slight modification of the database file format. It's just something that looks very like corrupted text. The word 'cnyrtpdeo' looks a bit like 'crypto' and 'oponed' looks like 'opened' and I think it's corrupted text. Yes. You are right. :( -- Dmitri Priimak Byte swap problems. The message is: failed to open database transaction 26 = file is encrypted or is not a database Oh my. We failed to rollback tra ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] is ticket 4037 not a bug?
This was brought up before by me here: http://sqlite.org:8080/cgi-bin/mailman/private/sqlite-users/2009-September/015484.html The response was: http://sqlite.org:8080/cgi-bin/mailman/private/sqlite-users/2009-September/015486.html Which said: According to http://www.sqlite.org/lang_select.html and http://www.sqlite.org/lang_expr.html one can use in select statement as a result column one of the following: - * - table_name.* (I assume that instead of table_name one can use table alias too) - any expression Expression can consist of the single column in the form [[database_name.]table_name.]column_name So nobody says that database_name.table_name.* should work and behavior is as intended and documented. Though from the point of view of outside user it seems logical for this to work of course. --- So perhaps this is a feature request? -Allan -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- boun...@sqlite.org] On Behalf Of Bogdan Ureche Sent: Tuesday, November 17, 2009 2:51 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] is ticket 4037 not a bug? I can imagine query generators tend to use more, possibly redundant, qualifiers than a human programmer would. -- ( Kees Nuyt ) c[_] That may be true but sometimes the qualifiers are needed to avoid ambiguity, in which case they are not redundant. Bogdan ___ 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
[sqlite] Feature Request Discussion: Virtual Table Column Use identification
Hi Folks,
I need to know what columns of my virtual table implementation are used for a
particular query or not. The computation of the columns is expensive and cannot
be deferred until the call to xColumn(). Thus I need to know before the first
row is fetched so that I can be efficient in my operation of the virtual table.
I have found a solution that works for me, but it is a minor breaking change
for some of the existing virtual table implementations. I have modified the
vdbe.c engine so that after opening the virtual table (OP_VOpen) that it scan
the current microcode for columns (OP_VColumn) used by that cursor. I then call
xColumn() with the pContext set to NULL (that's the breaking change). The
NULL indicates to my implementation that the column will be used in the query
that is about to happen. In my xOpen() routine I initialize things to keep
track of what is used and then identify which columns are used through the call
to xColumn().
For existing implementations the required change would be to test pContext and
return immediately.
My questions for the group are:
Is this a reasonable extension / feature to add to virtual table
implementations? I need it, but would this help others as well?
Would surrounding this new code with a PRAGMA option help with respect to the
breaking change. These interfaces are experimental, but are being used by
many. The amount of time used to find these opcodes is small, so I do not think
this is an efficiency issue. Rather it is a way to gently introduce this
concept.
Is there another way to do this that is not a breaking change?
Comments? Questions?
Thanks,
-Allan
The patch for the modification against 3.6.18 release vdbe.c that implements
the above feature is below. This code is added *after* all the work for
OP_VOpen has been completed. I place this code in the public domain under the
same license as SQLITE3.
diff -r -u sqlite3/src/vdbe.c roqlite3/src/vdbe.c
--- sqlite3/src/vdbe.c 2009-09-28 13:34:11.0 -0600
+++ new/src/vdbe.c 2009-09-28 13:34:13.0 -0600
@@ -5173,6 +5173,18 @@
pModule-xClose(pVtabCursor);
}
}
+ if( SQLITE_OK==rc ){
+// Help virtual table module with knowledge of which columns are used
+int i ;
+
+// Scan all opcodes for references to virtual columns associated with this
cursor
+for(i=0; ip-nOp; i++){
+ Op *anOp = p-aOp[i];
+ if ( anOp-opcode == OP_VColumn pOp-p1 == anOp-p1 ) {
+rc = pModule-xColumn(pVtabCursor, NULL, anOp-p2);
+ }
+}
+ }
break;
}
#endif /* SQLITE_OMIT_VIRTUALTABLE */
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Inconsistency in mutex.h and mutex.c
At the bottom of mutex.h there is an: #ifdef SQLITE_MUTEX_OMIT ... #endif /* defined(SQLITE_OMIT_MUTEX) Either the comments or the define should be changed. This occurs in mutex.c as well. The pattern for all other OMIT definitions is SQLITE_OMIT_% so it would be nice if this one could be changed to stay consistent with the rest. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Inconsistent behavior - perhaps a bug?
$ bin/sqlite3 SQLite version 3.6.17 Enter .help for instructions Enter SQL statements terminated with a ; sqlite create table t(a integer); sqlite select main.t.* from t; SQL error: near *: syntax error sqlite select main.t.* from main.t; SQL error: near *: syntax error sqlite select t.* from t; sqlite select t.* from main.t; sqlite select main.t.* from main.t; SQL error: near *: syntax error sqlite select main.t.a from main.t; sqlite select main.t.a from t; sqlite .quit ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] shared library location on Linux question
Subject: [sqlite] shared library location on Linux question I'm trying to run a .NET program on Linux using MONO that makes use of SQLite and nHibernate. I've got the managed code only System.Data.SQLite.dll and use the sqlite3.dll on Vista and my program and tests run fine. However, I don't know where to put the sqlite- 3.6.17.so shared library, or if there are other paths or settings I need to configure to use SQLite on Linux. I'm getting the following exception and any advice would be greatly appreciated. Thanks in advance, Dan SchemaExport: sqlite3_open_v2 System.EntryPointNotFoundException: sqlite3_open_v2 at (wrapper managed-to-native) System.Data.SQLite.UnsafeNativeMethods:sqlite3_open_v2 (byte[],intptr,int,intptr) at System.Data.SQLite.SQLite3.Open (System.String strFilename, SQLiteOpenFlagsEnum flags, Int32 maxPoolSize, Boolean usePool) [0x0] at System.Data.SQLite.SQLiteConnection.Open () [0x0] at NHibernate.Connection.DriverConnectionProvider.GetConnection () [0x0] at NHibernate.Tool.hbm2ddl.SchemaExport.Execute (Boolean script, Boolean export, Boolean justDrop, Boolean format) [0x0] Try: export LD_LIBRARY_PATH=/some/path/to/where/sqlite3/lib/resides Otherwise it expects the library to be in the typical places such as /usr/lib. -Allan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
