Re: [sqlite] Query locking up SQLite

On 2005-07-25 at 14:51:13 [+0200], David Fowler <[EMAIL PROTECTED]> wrote: > Well the query isn't that strange, I have 3 values that need matching > per-record returned, all in different tables (takes care of 3 tables) the > actual data I want is stored in another related table, and 2 of the valu

Re: [sqlite] Query locking up SQLite

On 2005-07-25 at 13:06:42 [+0200], David Fowler <[EMAIL PROTECTED]> wrote: > SELECT count(*) FROM table1 > INNER JOIN table2 ON (table1.id = table2.rel_id) > INNER JOIN table3 ON (table3.rel_id = table2.id) > INNER JOIN table4 ON (table3.id = table4.rel_id) > INNER JOIN table5 ON (table5.rel_id =

Re: [sqlite] Query locking up SQLite

T * approach with names colliding, especially when you start adding UNIONs. It is always advisable to use explicit relational variable names (columns). Charlie -- Charlie Clark Communications Manager yellowTAB GmbH Tel: +49-211-600-3657 http://www.yellowtab.com mailto: [EMAIL PROTECTED]

Re: [sqlite] Query locking up SQLite

of why I use explicit JOINS. SELECT * FROM table1 INNER JOIN table2 ON (table2.id = table1.table2_id) WHERE table1.value LIKE '%value%' OR table1.value LIKE '%value%') Doesn't this do what you want? -- Charlie Clark Communications Manager yellowTAB GmbH Tel: +49-211-600-3657 http://www.yellowtab.com mailto: [EMAIL PROTECTED]

Re: [sqlite] I still think it's a bug, 0 rows, no fieldnames

On 2005-07-24 at 16:11:26 [+0200], Edwin Knoppert <[EMAIL PROTECTED]> wrote: > Why defending it? > It's prob. a simple issue. > Besides, why i want the names, why should a system need to parse a query? > You approach this way to 'static' imo (what you enter is your result). > You can easily say t

[sqlite] Problem with building sqlite3

k yet. Thank you very much Charlie Clark