On 25 Mar 2011, at 11:11pm, Jay A. Kreibich wrote:
> On Fri, Mar 25, 2011 at 10:30:59PM +, Simon Slavin scratched on the wall:
>
>> Actually I'm surprised and not terribly impressed that SQLite ever
>> does a scan when there's an ideal index available.
>
> Why? Do you want it to run slowe
On Fri, Mar 25, 2011 at 10:30:59PM +, Simon Slavin scratched on the wall:
> Actually I'm surprised and not terribly impressed that SQLite ever
> does a scan when there's an ideal index available.
Why? Do you want it to run slower?
Indexes are not magic bullets. Using an index to retrie
> Suggestion: After you run ANALYZE, go back and modify values in
> sqlite_stat1 (and sqlite_stat2 if you are using SQLITE_ENABLE_STAT2) with
> "typical" values that you would expect to see in most databases. Yes, you
> can read and write the sqlite_stat1 and sqlite_stat2 tables. Maybe you can
>
On Fri, Mar 25, 2011 at 6:30 PM, Simon Slavin wrote:
>
> On 25 Mar 2011, at 10:18pm, Richard Hipp wrote:
>
> > Suggestion: After you run ANALYZE, go back and modify values in
> > sqlite_stat1 (and sqlite_stat2 if you are using SQLITE_ENABLE_STAT2) with
> > "typical" values that you would expect
On 25 Mar 2011, at 10:18pm, Richard Hipp wrote:
> Suggestion: After you run ANALYZE, go back and modify values in
> sqlite_stat1 (and sqlite_stat2 if you are using SQLITE_ENABLE_STAT2) with
> "typical" values that you would expect to see in most databases. Yes, you
> can read and write the sqli
On Fri, Mar 25, 2011 at 5:24 PM, Eric Minbiole wrote:
> We have an application that has been using SQLite successfully for several
> years. We use SQLite for various purposes within our product, with a few
> dozen tables overall.
>
> Recently, I started to upgrade from version 3.6.3 to 3.7.5. D
We have an application that has been using SQLite successfully for several
years. We use SQLite for various purposes within our product, with a few
dozen tables overall.
Recently, I started to upgrade from version 3.6.3 to 3.7.5. During that
time, I noticed that several previously fast indexed q
J Trahair wrote:
> Hi. I've noticed that SELECT statements are specific to the capitalisation of
> the WHERE section.
>
> Suppose I have a Customers table with a CustomerCode field, and a value in
> one of the records of TRA001, eg:
>
> CustomerCode CustomerName
> TRA001 Trahair
On Fri, 25 Mar 2011 10:35:37 +0100
"J Trahair" wrote:
> If the SELECT statement is SELECT * FROM Customers WHERE CustomerCode =
> 'tra001' that is, with tra001 in lower case, SQLite *does not find the
> record*.
SELECT * FROM Customers WHERE CustomerCode LIKE 'tra001'
would do. There are excepti
J Trahair writes:
[...]
> SELECT * FROM Customers WHERE CustomerCode = 'tra001'
> that is, with tra001 in
> lower case, SQLite *does not find the record*.
[...]
use LIKE (http://www.sqlite.org/lang_expr.html#like)
SELECT * FROM Customers WHERE CustomerCode LIKE 'tra001'
Oliver
On Fri, Mar 25, 2011 at 2:35 AM, J Trahair
wrote:
> Hi. I've noticed that SELECT statements are specific to the capitalisation of
> the WHERE section.
>
> Suppose I have a Customers table with a CustomerCode field, and a value in
> one of the records of TRA001, eg:
>
> CustomerCode CustomerNam
Hi. I've noticed that SELECT statements are specific to the capitalisation of
the WHERE section.
Suppose I have a Customers table with a CustomerCode field, and a value in one
of the records of TRA001, eg:
CustomerCode CustomerName
TRA001 Trahair
SMI001 Smith
If the
12 matches
Mail list logo