> Looks strange, many changes now, today, in short time. But I cannot
> judge what is changed, some one should take a look at it.
That may have been me
When I saw there was the spam warning I had a look and discovered
many pages were completely replaced with
http://www.porn.link//whatever1000
I tried the data you mentioned in SQLite Explorer and the SQL
statemen worked correctlyt:
> select * from tResult where tex like '%ra%'
returned the expected record perfectly
Here is the output of the command line test
SQLite version 3.3.3
Enter ".help" for instructions
sqlite> .schema
I'd say leave it as it is .. ie "12.34" is a string "12.34" is a
number
This way you have all the options you need and it's up to the coder
to decide what they want.
If " 12.34" is a string it's fine
If " 12.34" is *NOT* a string, then TRIM it and pass it SQLite
cleaned up
If you
We have the same issue, to get around it we fire a thread when the
program starts, intelligently "touching" every table that the user is
likely to access (As Michael Sizaki already mentioned a select
count(last_column) from big_table; will do it)
Since a user is very unlikely to run a program
I created your schema and saved the single line you provided to a
file and it all imported fine:
sqlite> .nullvalue NULL
sqlite> .separator ;
sqlite> .import text.txt Cliente
sqlite> select * from cliente;
1|2005-02-13 00:00:00|FRANCISCO EDNAN SABOIA PONTES |0|R|NEWTON
PARENTE|1161|PRO
XIMO AO
Are you wrapping the transactions in between Begin/End Transactions?
BEGIN TRANSACTION;
INSERT INTO table (foo) VALUES (bar);
INSERT INTO table (foo) VALUES (par);
INSERT INTO table (foo) VALUES (tar);
INSERT INTO table (foo) VALUES (far);
..
INSERT INTO table (foo) VALUES (car);
INSERT INTO
> For what it is worth I did some trials in matching page size to the
> underlying virtual memory page size and was surprised to find that I did
> not measure any significant performance change. My guess is that it is
> the structure of the data in your application which would be sensitive
>
I'm using threads and SQLite on a Win32 system
I can tell you that things may work 100% for ages, then one day, the
moons align and the threads will fall over each others feet
It may happen later, rather than sooner, and may not even happen in
your lifetime, but it'll happen :)
> I wasn't
> You can load sqlite into memory?
> I do have 2GB of RAM.
You can pass ":memory:" to the sqlite_open command to open a SQLite
database in memory I think it is
I imagine this will speed up your retrievals but without an index it
will still be slower that it should be.
With an index I imagine
I recommend not using SDB (on windows machines)
SQLite DataBase sounded like a good name too :)
That is the default extension for something called "Appfix Package"
and in certain circumstances, Windows will automatically back the DB
up every time it is changed thinking that a DLL or
> Interesting. But, with the above suggestion, every INSERT or DELETE
> would slow down anyway as much as it would have were SQLite to maintain
> meta information itself, no?
>
> .
>
> Hence, it might be worthwhile maintaining the meta information no
> matter what... most of the folks
I looked around, the FAQ, Wiki and history of this list but didn't
see any solid reply
Does anyone know what the maximum number of tables a SQLite 3.0
database can hold?
We've got one that has 11k or so and it seems fine, but I am worried
we may hit a limit
> When I launch the program with the Terminal, if I write:
> ./quickStart test.db "select * from personne", all occurs well, I
> receives the data contained in the table "personne". But if I write
> ./quickStart test "select * from personne", therefore I the extention in
> the name of the data
On 6 Apr 2005 at 3:13, Dan Kennedy wrote:
Date sent: Wed, 6 Apr 2005 03:13:58 -0700 (PDT)
From: Dan Kennedy <[EMAIL PROTECTED]>
Subject:Re: [sqlite] Access Violations in sqlite3_step when in
DLL
To: sqlite-users@sqlite.org,
> Sounds like the calling type is different. Do you know if the EXE is
> calling your stuff using stdcall or cdecl, and does it match your
> functions? If you don't specify, your functions are cdecl. I've seen
> this kind of thing when they don't match. It may work a couple of
> times, but
We have been using SQLite3 for a while now without issues. We are
running a EXE calling a DLL (Which calls a DLL which eventually uses
the SQLite functions)
These two DLL's are both written in Delphi - in Windows (with a
delphi wrapper that runs the SQLite DLL)
This code has worked fine under
> Is it possible to query the database to see if it's 2.x or 3.x, we
need to
> know if the rowid's are 32 or 64 bit and we don't know what version we
> might be running on?
You can check the DB file header. The first 16 characters are "SQLite
format 3\000" if it is version 3+
Check out
On 25 Feb 2005 at 9:38, Neelamegam Appadurai wrote:
> Could anyone please give me reason for variation in performance
> between linux and windows.
How are you testing this performance? Do you have a program written
in windows and another written for linux? If so, the code/mechanism
of DB
On 23 Feb 2005 at 18:36, Nathan Kurz wrote:
> But maybe I'm not really understanding the advantages of the in-memory
> database. Is it in some way inherently faster on lookups than just
> setting SQLite to use a really large cache?
Well the way I think of it is the if you don't need to keep the
> I have a Delphi SQLite wrapper.
> It can Open database, run sql-s, etc.
>
> But I don't know, how to I set page size, because when I do open in
> database, the pragma is not working, and when I try to exec sql before
> open database, the wrapper is say: database not opened...
>
> Anybody
> SQLiters:
> what would be the most efficient method for creating an exact copy of an
> existing table with all the columns and data of the existing table?
You could just do this from commandline in SQL like so:
CREATE TABLE newTable AS SELECT * FROM oldTable;
That makes a new tables, same
> standard VCL stuff so there's a little overhead. But surely not as dramatic as
> suggested. But there's one condition. Use transactions! Without them, you'll
> never get a good performance.
Perhaps not dramatic no, but I was getting to the point where I am
setting DB page sizes to match OS
> I wouldn't sell the BDE-style components short, as they may be useful
> for some, if well-written and well-documented, but I like simple.
Oh quite true, but in my case (and really what I was trying to get at
in that monotribe) was to get the speediest database access, you'd be
better server
> Make a wiki page.
Not a bad idea :) Done
I've been posting a lot on speed and SQLite, just thought I'd dump
the results and findings into one message including a nice example on
how dumb you can get in the hopes no one else falls this low :)
After several weeks of playing with SQlite3 we have finally gotton
what we want out of a DB.
> I think you people are missing the point here, the performance increase
> you're seeing is all down to OS caching and will vary across different
> ports. It's nothing to do with sqlite, and will affect every package.
>
> Therefore the only way to fairly compare mysql/postgress/sqlite is to
> Another trick you can pull is to create an index that
> contains every column in the table with the cluster index
> columns occuring first. That will double the size of your
> database. But when SQLite can get all of the information it
> needs out of the index it does not bother to consult the
> Doing a keyed search is no guarantee that you won't touch *every* single
> page in the table, if the rows are inserted in random order. Try this:
...cut...
> Assuming key is the key field you want, the records will be inserted into
> wibble in key order. Selecting by key will then touch the
> I would be interested to know the results for very large data sets.
> Indications on the list have been that performance suffers when the number
> of records gets very big (> 1 million), possibly due to using an internal
> sort.
I must say, with a 2+ million row data set, we aren't getting
> I am using SQLite 3.0.8 in a Win32 threaded
> environment.
>
> I keep getting random "Database schema has changed"
> errors even though I am using thread local
> storage to make sure sqlite3_open() gets called
> on each thread and a there is a sqlite3* per thread.
>
> Has anyone had any luck
> Did you try www.aducom.com/sqlite, you can create it dynamically in your
> code or use it as VCL-component.
> It also works in Delphi6
>
> Use the Database component and the Query component, you get a
> tdataset-alike resultset.
That's the one we were using initially that seemed slow. I
Tried to compile your wrapper this morning with no luck
The code seems to be written with Delphi 7 or higher? We are still
using delphi 6 which doesn't have the SysUtils data structure
TFormatSettings, and the functions FormatDateTime have different
declarations (only 2 paramaters)
Those
No, the DLL wasn't the issue (heck the entire program is a DLL anyway
and that's worked well for ages)
We eventually discoverd through profiling the Delphi componants we
had started using were the slow point, tossed them, and tried someone
elses version (some stuff adapted by someone called
> H The fact that the freelist size is different
> suggests either a bug in sqlite3_analyzer or a corrupt
> database file. What does "PRAGMA integrity_check" say?
It returned a batch of Page not used (from about 4 to 48 I think).\
That was it
> What OS did you say you are using?
> > CREATE INDEX myMyIndex ON myTable (myKey);
> > CREATE UNIQUE INDEX [pkPrimary] ON [myTable] ([myKey], [NumOne]);
> > CREATE INDEX myNumOneIndex ON myTable (NumOne);
>
> Why did you chose these indexes?
> Updates and Inserts are faster with fewer indices.
> Perhaps they can be reduces?
>
>
> Out of curiousity, have you tried doing a plain INSERT instead of INSERT
> OR REPLACE INTO?
> Since you have no unique fields in your table, I'm not exactly sure how
> or why you might get an
> INSERT failure, but perhaps Sqlite is doing some sort of data comparison
> on each insert.
We have
> The myMyIndex will only slow you down. myNumOneIndex
> will help if you have queries that use the numOne column.
Hurm, yes that makes sense. it wasn't supposed to be there, but was
added just incase it helped, which it didn't
> What is the output from sqlite3_analyzer?
Unfortunatly didn't
Ok I hadn't toyed with those. Just tried it, the speed for queries
hasn't increased much, but a little
However, I started getting hard drive thrashes for 10+ seconds from
time to time. Will investigate the cahce further to see what suits
this app
> Did you try increasing the page cache size.
> What speed were you expecting?
> Are you comparing it to another database? If so what are the results for that
> database?
Anything better than what we got. The results are the worst we have
gotton from any DB or any self rolled data system (Jet is better, het
shouldn't be better)
After more
I've got a 6 million row DB in SQLite 3, but getting... odd results
which don't match up with the speed tests I've seen
The statement:
SELECT * FROM myTable WHERE myKey=1000
takes between 1 second to 4 or 5 on spikes. The returned result set
is ~2000 records. I havn't seen more than 2000
40 matches
Mail list logo
