On Jun 21, 2008, at 1:27 AM, Matt Sergeant wrote:
> On Thu, 19 Jun 2008 12:05:56 -0400, D. Richard Hipp wrote:
>>
>> On Jun 19, 2008, at 11:49 AM, Matt Sergeant wrote:
>>>
>>> Note that there are some C++ style comments crept back into the code
>>> (I
>>> noticed in the amalgamation, so I can't
> printf-8.2...
> Expected: [2147483647 2147483648 4294967295]
> Got: [2147483647 18446744071562067968 18446744073709551615]
>
> The code looks like:
>
>
> ...
> do_test printf-8.2 {
> sqlite3_mprintf_int {%lu %lu %lu} 0x7fff 0x8000 0x
> } {2147483647 2147483648
I am trying to make my first MonoDevelop program using SQLite as the
database. I have been unable to find a data provider. Does anyone know of a
SQLite data provider for MonoDevelop 1.0? If there is one, an example of how
to incorporate it into a MonoDevelop program would be appreciated. I am new
Try to do an explain on the query you are running. Make sure its the same on
windows and the hp system. (it should be using the same index).
On HP, the default sector size is 1k. You might try rebuilding your database to
use a block size of 1k or greater. If you are using veritas filesystem or
В сообщении от Friday 20 June 2008 03:00:21 Stephen Woodbridge написал(а):
> This looks interesting:
> http://sqlitedbms.sourceforge.net/index.htm
>
> Alexey would this work for your multi-master replication? Maybe you
> modify this to work for the specific task you have in mind.
May be I can
Andrea Connell wrote:
> I was originally using LIKE but since that can't make use of indexing I
> found this as an alternative to attempt to speed up the query.
>
> So if I wanted to search PHONETIC_KEY LIKE 'ABCD%' I replace it with
> PHONETIC_KEY >= 'ABCD' AND PHONETIC_KEY < 'ABCE'
>
The
I understand that the machines will perform differently, but that
doesn't explain the differences I am seeing.
On Windows SQLite can do 1,000 rows of input in less than a second and
our in house system can do it in just over a second. They are fairly
comparable at this point. When I increase the
On Thu, 19 Jun 2008 12:05:56 -0400, D. Richard Hipp wrote:
>
> On Jun 19, 2008, at 11:49 AM, Matt Sergeant wrote:
>>
>> Note that there are some C++ style comments crept back into the code
>> (I
>> noticed in the amalgamation, so I can't give you a direct pointer to
>> them). This causes
I was originally using LIKE but since that can't make use of indexing I
found this as an alternative to attempt to speed up the query.
So if I wanted to search PHONETIC_KEY LIKE 'ABCD%' I replace it with
PHONETIC_KEY >= 'ABCD' AND PHONETIC_KEY < 'ABCE'
-Original Message-
From: [EMAIL
Hi Andrea,
I'm interested in your query:
Andrea Connell wrote:
> char * qry = "SELECT * FROM LEVEL1 WHERE COUNTRY_ID = ? AND
> DIR_SEARCH_AREA1 = ? AND ADDRESS_TYPE = ? AND PHONETIC_KEY >= ? AND
> PHONETIC_KEY < ? ;";
>
> char * qry2 = "SELECT * FROM LEVEL2 WHERE
> PARENT_KEY = ? AND
You are measuring the speed of the respective machines. Benchmark each
one to get relative performance.
Andrea Connell wrote:
>
> Sorry somehow I sent that before I was quite finished. I'm just
> wondering if there is anything else I should try. About 30,000 rows are
> found in the end, and
I ran into this with SQLite3 3.5.4:
printf-8.2...
Expected: [2147483647 2147483648 4294967295]
Got: [2147483647 18446744071562067968 18446744073709551615]
The code looks like:
...
do_test printf-8.2 {
sqlite3_mprintf_int {%lu %lu %lu} 0x7fff 0x8000 0x
} {2147483647
Sorry somehow I sent that before I was quite finished. I'm just
wondering if there is anything else I should try. About 30,000 rows are
found in the end, and it can do this on Windows in less than a second.
I'm convinced it shouldn't take 30 seconds on HP. I know the OS's
caching method will
Now that I have SQLite compiled on HP, I am starting to test
performance. So far it's pretty disappointing though.
I am comparing performance of SQLite versus an in-house directory access
system. I have the same table structure and data for each of them. The
code reads some data from an input
Hi Gilles,
'like' is case-insensitive.
so:
select * from customers where city like "%ville%";
would match "villes" or "VilleS".
Rgds,
Simon
2008/6/20 Gilles Ganault <[EMAIL PROTECTED]>:
> Hello
>
> Is there a way for glob to be case-insensitive? I'd like to retrieve
> all rows where the city
В сообщении от Thursday 19 June 2008 17:40:14 Dennis Cote написал(а):
> Stephen Woodbridge wrote:
> > Well if the index requires fewer page reads then it should be
> > proportionally faster. For example if you can only get 5 rows on a page
> > but 25 index entries, you have 1/5 the number of pages
Hello
Is there a way for glob to be case-insensitive? I'd like to retrieve
all rows where the city name can be a mix of upper- and lower-case
letters, eg.
select * from customers where city glob "*ville*";
would match "ville" or "Ville".
Thank you.
> I use mutexes set up as read or write locks around Sqlite to synchronize
> access.
In Sqlite 3.5.9 function "db timeout" work fine, I was test it. So internal
mutex is enough now, I think.
___
sqlite-users mailing list
sqlite-users@sqlite.org
18 matches
Mail list logo
