I have the next table
table1( id INTEGER, name VARCHAR, id2 INTEGER, name2 VARCHAR, year INTEGER
);
I have created the next indexes : index1( name ), index2( id2 ), index3(
name2 );
The database have about 200,000 records.
The next query takes about 2 seconds and I think its too much.
SELECT id
Je serai absent(e) à partir du 29/06/2010 de retour le 30/06/2010.
Je répondrai à votre message dès mon retour.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
absolutely no problem with sqlite.
ensure you are doing smallest update as possible.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
On 28 Jun 2010, at 7:31pm, Pavel Ivanov wrote:
>> Such freedom is not suitable for data interchange between two systems. Not
>> that SQLite or any other database would change the PK during import-export,
>> but they are free to do so as long as the *intramural* integrity is
>> preserved.
>
> Ca
Hello
Using the script below to build an ipkg package for OpenWrt, I need to
add the command-line exe, ie. sqlite3.exe on Windows:
=
# cat sqlite3.mk
#
# sqlite3 for the Blackfin
# David Rowe March 2008
#
# usage: make -f sqlite3.mk sqlite3-package
#
# Thanks OpenWRT for bui
My remarks were made in the context of AUTOINCREMENTING primary keys. With
auto-incremented keys, the database is free to implement the incrementation
in the manner it sees fit. It may skip numbers. It may re-generate keys on
import/restore and cascade the changes out to child tables. Given these
On Mon, Jun 28, 2010 at 02:15:01PM -0400, Tim Romano scratched on the wall:
> Since no SQL standard requires the primary key to do anything other than be
> unique within the relation and with respect to its foreign references. As
> long as the database maintains meets those requirements, it is fr
> Such freedom is not suitable for data interchange between two systems. Not
> that SQLite or any other database would change the PK during import-export,
> but they are free to do so as long as the *intramural* integrity is
> preserved.
Can you point out some documentation supporting this claim?
Oliver Peters wrote:
> example_01:
> --
> CREATE TABLE doesntwork(
> idINTEGER PRIMARY KEY AUTOINCREMENT,
> someint INTEGER,
> sometext TEXT,
> UNIQUE(someint)
> );
>
> INSERT INTO doesntwork(someint,sometext) VALUES(2,'Douglas Adams');
>
> example_02:
> --
Pavel,
Although you are right that SQLite persists the rowid for INTEGER PRIMARY
KEYS across VACUUMs and suchlike, I too am right.
I was focusing on the OP's use of the words "guaranteed" and "globally" and
on this requirement:
The OP wrote:
"BTW, in my story it is necessary to store the unique I
Ian,
You might try Berkeley DB 11gR2 (read: Berkeley DB and SQLite combined) it
allows you to run multi-process access to a SQLite database and scales really
well.
http://download.oracle.com/berkeley-db/db-5.0.21.tar.gz
Give it a whirl and then let me know what you think.
-greg
> -Origin
Igor,
Happy to help. :) First IANAL and what I'm about to say is a GROSS
simplification of intricate intellectual property law so with that in mind.
The Sleepycat License basically says, "anything that includes/uses/calls-into
Sleepycat Licensed software (in this case Berkeley DB) and is red
> step 3: try to delete/update records from the table "doesntwork" from within
> the
> frontend (OpenOffice 3.2.1)
>
> The result from within Base is as the tablename indicates (doesn't work). And
> from that point I don't know what to do besides saying: "that has to be an
> error
> in the ODBC-d
Pavel Ivanov writes:
[...]
> And as no one experienced problems like yours before then I guess we
> can switch contexts and now "frontend" will mean the app that uses
> this ODBC driver (probably you use it through some wrapper or
> something else is standing in the way).
o.k. - good hint: I tr
On Mon, Jun 28, 2010 at 11:30:49AM -0400, Eric Smith wrote:
> From the docs:
>
> > Under Unix, you should not carry an open SQLite database across a
> > fork() system call into the child process. Problems will result if you
> > do.
>
> What if I fork a process that promises not to use the handle,
I am out of the office until 07/01/2010.
I'm out of the office but checking email once or twice a day and will
respond to any high importance issues as quickly as possible.
Note: This is an automated response to your message "sqlite-users Digest,
Vol 30, Issue 27" sent on 6/28/10 6:00:02.
Th
Israel Lins Albuquerque writes:
>
>
> maybe this works for you!
>
> http://www.patthoyts.tk/sqlite3odbc.html
in the first sentence he writes: go to http://www.ch-werner.de/sqliteodbc/
-> outdated
> http://wiki.services.openoffice.or/wiki/SummerOfCode2006#Native_SQLite_driver
-> very outda
There are some here:
http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers (I've found this
page through google ;-) ). But AFAIR yours one is the most popular.
And as no one experienced problems like yours before then I guess we
can switch contexts and now "frontend" will mean the app that uses
this
maybe this works for you!
http://www.patthoyts.tk/sqlite3odbc.html
http://wiki.services.openoffice.org/wiki/SummerOfCode2006#Native_SQLite_driver
- "Oliver Peters" escreveu:
> Pavel Ivanov writes:
>
> [...]
> >
> > If your ODBC driver doesn't allow you to have any UNIQUE constraint
>From the docs:
> Under Unix, you should not carry an open SQLite database across a
> fork() system call into the child process. Problems will result if you
> do.
What if I fork a process that promises not to use the handle, and
furthermore the child process certainly dies before the parent does?
Pavel Ivanov writes:
[...]
>
> If your ODBC driver doesn't allow you to have any UNIQUE constraint
> then, as Darren said, you better consider using some other driver, not
> a workaround for this one. I believe there are several ODBC drivers
> for SQLite out there.
>
I strongly believe in huma
On Mon, Jun 28, 2010 at 10:07 AM, Serdar Genc wrote:
> I have already tried it but not working.. :(
>
Works for me.
punk...@lucknow ~$sqlite3
-- Loading resources from /Users/punkish/.sqliterc
SQLite version 3.6.23
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>
I have already tried it but not working.. :(
On Mon, Jun 28, 2010 at 6:01 PM, P Kishor wrote:
> On Mon, Jun 28, 2010 at 9:58 AM, Serdar Genc
> wrote:
> > Hi everyone,
> >
> > I have a problem related to column names . I have a column name as a[b]
> in
> > my table but
> > this creates a problem
> ODBC-Driver == frontend ???
In this context - probably, yes.
> I'am pretty sure that it's an odbc-driver problem (so nothing to worry in this
> group?) and I posted her for a workaround as short and elegant like the UNIQUE
> constraint I am not allowed to use.
If your ODBC driver doesn't allow
On Mon, Jun 28, 2010 at 9:58 AM, Serdar Genc wrote:
> Hi everyone,
>
> I have a problem related to column names . I have a column name as a[b] in
> my table but
> this creates a problem when using SELECT statement as
> SELECT a[b] from Table. I know [] is a special character but How would I
> tell
Pavel Ivanov writes:
>
> > there are no NULLS in my example and I don't believe in a frontend-problem
> > (I
> > wouldn't interpret the SQL.LOG this way).
>
> If you don't believe that it's your frontend problem then go ahead and
> reproduce it in sqlite3 command line utility. If you were able
Hi everyone,
I have a problem related to column names . I have a column name as a[b] in
my table but
this creates a problem when using SELECT statement as
SELECT a[b] from Table. I know [] is a special character but How would I
tell SQlite that field
name is a[b] and I am not using [] with a speci
Thanks a lot for this link!
2010/5/12 Roger Binns
>
>
> http://www.sqlite.org/cvstrac/tktview?tn=2604
>
> To fix it requires code changes to SQLite and the SQLite team haven't
> deemed
> this necessary (yet).
>
> --
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
_
> there are no NULLS in my example and I don't believe in a frontend-problem (I
> wouldn't interpret the SQL.LOG this way).
If you don't believe that it's your frontend problem then go ahead and
reproduce it in sqlite3 command line utility. If you were able to
reproduce it there then it would be i
> the primary key column [id] is defined as INTEGER PRMARY KEY; so defined,
> SQLite will treat this column as an alias for the ROWID. There is no
> guarantee that ROWID will remain constant over time: its job is very simple:
> to be unique. There is no "be constant" clause in its contract, so to
You could also define your primary key as INT PRIMARY KEY (rather than
INTEGER PRIMARY KEY) and in that case SQLite will treat it as a normal
column and it will remain immutable over time (unless you change it).
However, I would advise against using INT PRIMARY KEY inasmuch as this
subtle (yet docu
And myspecialvalue can be INTEGER|TEXT.
On Mon, Jun 28, 2010 at 8:39 AM, Tim Romano wrote:
> In this example:
>
> CREATE TABLE tableA {
>
> id INTEGER PRIMARY KEY AUTOINCREMENT,
> name TEXT NOT NULL UNIQUE,
> myspecialvalue TEXT NOT NULL UNIQUE
> }
>
>
>
>
__
In this example:
CREATE TABLE tableA {
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL UNIQUE,
myspecialvalue TEXT NOT NULL UNIQUE
}
the primary key column [id] is defined as INTEGER PRMARY KEY; so defined,
SQLite will treat this column as an alias for the ROWID. There is no
guaran
Tim Romano writes:
>
> Could there be an issue with the character-encoding of the text column?
> Regards
> Tim Romano
> Swarthmore PA
>
[...]
I don't see this as a possibility because:
1. my encoding is utf-8
2. the simple example
http://article.gmane.org/gmane.comp.db.sqlite.general/57581 h
Could there be an issue with the character-encoding of the text column?
Regards
Tim Romano
Swarthmore PA
On Fri, Jun 25, 2010 at 12:35 PM, Oliver Peters wrote:
> Igor Tandetnik writes:
>
> [...]
>
> > Isn't that exactly what you were asking for - a different syntax to
> achieve
> the same end r
Darren Duncan writes:
[...]
> What efforts have you made in trying to fix the front-end instead?
>
Nothing because I'm not a programmer but I reduced complexity:
example_01:
--
CREATE TABLE doesntwork(
idINTEGER PRIMARY KEY AUTOINCREMENT,
someint INTEGER,
sometext
36 matches
Mail list logo