On Fri, Mar 10, 2006 at 04:37:36PM -0800, Darren Duncan wrote:
> 3. There is no such thing as a NULL.
>
> 3.1 All logic is 2VL (true, false) not 3VL (true, false, unknown).
There is no such thing as null, really? So, when you do an outer join
between two tables, which in SQL would produce
You're right Darren, but the problem is that we're not in a DB class. We
cannot tell people who have a solution for their problems that "your
solution is wrong. You need to reimplement your stuff to make it right".
Most of SQLite users are practical people, and all they want is their
problem to be
Just for the record:
it wouldn't require any significant amount more code.
Yes it would. My code currently approximates to this:
cursor.execute("insert into foo (x,y,z) values(?,?,?)", x,y,z)
It would have to change into this:
# column x is defined as string
if isinstance(x, string):
At 6:52 PM -0800 3/10/06, Roger Binns wrote:
Only for some applications. It would be harder to use for
my apps. Specifically manifest typing as currently implemented
in SQLite is a perfect match for apps writen in Python (which
also uses manifest typing). It would require a lot more code
to
"Boris Popov" <[EMAIL PROTECTED]> wrote:
> There's a problem with LIKE in queries produces inconsistent results,
> whereas = works as expected,
>
> CREATE TABLE TYPETESTS (test blob NULL , id integer NOT NULL)
> INSERT INTO TYPETESTS (test,id) VALUES (X'616263646566',349)
>
> SELECT TEST,ID FROM
In doing all of the above, SQLite should actually be simpler to
implement, and it will be easier to use, with more predictable
results and fewer bugs.
Only for some applications. It would be harder to use for
my apps. Specifically manifest typing as currently implemented
in SQLite is a
- Original Message
> From: Christian Smith <[EMAIL PROTECTED]>
> But SQLite depends on the OS caching abilities for much of it's
> performance. Removing it is like saying SQLite is rubbish on Intel
> processors after testing on a i486.
yes and no: while it's nice to be able to rely
- Original Message
> From: [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> >
> > One question though: are the file access "sorted", so that seeks are
> > minimised when performing a transaction (making the assumption that
> > the file is not fragmented on disk)?
> >
> I'm not sure
All, and particularly Dr. Hipp,
Lately, my own database project in Perl, named Rosetta, has evolved
to officially be an implementation of Chris Date's and Hugh Darwen's
proposal for relational databases called "The Third Manifesto", which
is talked about at http://www.thethirdmanifesto.com/
cstrader wrote:
I'm looking to enhance query speed. Does it matter what variable type I use as the primary key? I'm thinking numbers might be faster than strings, but I'm not sure.
Thanks!
Integer primary keys will be the fastest since SQLite optimizes this
case by not creating a
<[EMAIL PROTECTED]> wrote:
>
> One question though: are the file access "sorted", so that seeks are
> minimised when performing a transaction (making the assumption that
> the file is not fragmented on disk)?
>
I'm not sure what you are asking. Can you restate your question?
--
D. Richard
Christian Smith <[EMAIL PROTECTED]> wrote:
> >
> >3. Extend the sqlite3_open commands to support URI style path
> >references in order to specify the file system locking type (as
> >opposed to modifying the arguments list). After a little poking
> >around on RFC 3986
Helmut Tschemernjak <[EMAIL PROTECTED]> wrote:
> The current lock offset will not allow to copy open DB files if the
> database gets larger than 0x4000 bytes. This is because locked
> regions cannot be copied under Windows, we changed it to:
>
> #define PENDING_BYTE
"Pam Greene" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm working on a system to add full-text indexing on top of SQLite in a
> semi-automated way. The general idea is that users will call an API to
> "register" a document table for indexing, and the system will take care of
> everything from
yklin <[EMAIL PROTECTED]> wrote:
> Hi,
> I recompiled sqlite (3.2.7) source in RedHat 9 (I upgrade kernel to
> 2.4.31). After all, "make test" reports lock test failed, why ? Is
> there any option in kernel need to turn on ? Do anyone have the same
> problem ?
>
There are bugs in the way
Hello!
My name is Bastian from Germany and I am new to this List. I hope I
respect all common rules by sending this message.
I usualy work whith MySQL. Now I whant to develope a software for
testing reasons. This shall behave like the old MySQL software but work
whith SQL Lite.
Now my
yes you are correct,
but even when i rewrite the typo, there was no result (i got
an empty one)
i mean with the originald table, not the present in letter
(i got it with sqlite explorer export function)
but when i select all from the db with sqlite.exe i saw,
that in this column the data was ...
>
> Jay... I could do that and maybe will. But does anyone know whether it
> SHOULD matter? Or are you saying that there are no general principles in
> this regard?
I would think the difference would be pretty minimal but I don't know for sure.
It would seem to be quicker to test than
Jay... I could do that and maybe will. But does anyone know whether it
SHOULD matter? Or are you saying that there are no general principles in this
regard?
Thanks..
On 3/10/06, cstrader <[EMAIL PROTECTED]> wrote:
> I'm looking to enhance query speed. Does it matter what variable type I use
> as the primary key? I'm thinking numbers might be faster than strings, but
> I'm not sure.
>
> Thanks!
>
>
Try it and see :)
I assume it is faster to key on only one variable rather than two?
Thanks
I'm looking to enhance query speed. Does it matter what variable type I use as
the primary key? I'm thinking numbers might be faster than strings, but I'm
not sure.
Thanks!
Thanks! The exec_table is helpful... I may get back to you for more
info on this. For now, I'm just querying row by row.
On Fri, 10 Mar 2006, James Austin wrote:
>I've been doing a fair bit of research into optimising larger tables and
>just want a bit of feedback (most of my lecturers are giving conflicting
>answers).
>
>Just say I have a table with 200+ fields (all relate uniquly to the primary
>key), when
On 3/10/06, James Austin <[EMAIL PROTECTED]> wrote:
> I've been doing a fair bit of research into optimising larger tables and
> just want a bit of feedback (most of my lecturers are giving conflicting
> answers).
Each database has it's own strengths and weeknesses and they may all
have different
[EMAIL PROTECTED] wrote:
thanks
actualy the problem was in the sqlite explorer because the
column was defined as integer and any text is interpreted
as zero :-)
no, actually i think Guillaume was correct.
This is the query you posted:
SELECT statid
FROM plan P1
WHERE P1.curseid = 0;
Note
thanks
actualy the problem was in the sqlite explorer because the
column was defined as integer and any text is interpreted
as zero :-)
Цитат на писмо от Guillaume MAISON <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] a ?crit :
> > hi guys
> > i need help :-)
> >
> > what is the problem :
> >
On Thu, 9 Mar 2006 [EMAIL PROTECTED] wrote:
>- Original Message
>> From: Christian Smith <[EMAIL PROTECTED]>
>
>> Is this a likely usage scenario? Will your application regularly
>> umount/mount the filesystem between transactions? While sounding
>> facetious, I'm not trying to. Your
[EMAIL PROTECTED] a écrit :
hi guys
i need help :-)
what is the problem :
(SQLite version 3.3.4, win XP)
i have a table:
CREATE TABLE plan(personid INTEGER, curseid INTEGER, statid
INTEGER);
INSERT INTO plan VALUES(1,1,0);
INSERT INTO plan VALUES(2,1,0);
INSERT INTO plan VALUES(3,1,0);
INSERT
hi guys
i need help :-)
what is the problem :
(SQLite version 3.3.4, win XP)
i have a table:
CREATE TABLE plan(personid INTEGER, curseid INTEGER, statid
INTEGER);
INSERT INTO plan VALUES(1,1,0);
INSERT INTO plan VALUES(2,1,0);
INSERT INTO plan VALUES(3,1,0);
INSERT INTO plan VALUES(4,1,NULL);
The question is more to do with theoretical optimisation rather than
improving the speed of that specific database (which was used only for
benchmarks), also note that the 700 record difference was based on around
5000 queries per second (definitly not a margin of error (this is a problem
with
The question is more to do with theoretical optimisation rather than
improving the speed of that specific database (which was used only for
benchmarks), also note that the 700 record difference was based on around
5000 queries per second (definitly not a margin of error (this is a problem
with
The question is more to do with theoretical optimisation rather than
improving the speed of that specific database (which was used only for
benchmarks), also note that the 700 record difference was based on around
5000 queries per second (definitly not a margin of error (this is a problem
with
The question is more to do with theoretical optimisation rather than
improving the speed of that specific database (which was used only for
benchmarks), also note that the 700 record difference was based on around
5000 queries per second (definitly not a margin of error (this is a problem
with
34 matches
Mail list logo
