[sqlite] RE: [RBL] Re: [sqlite] XML to SQLite upload

[Steve O'Hara]

This is the right approach, when I worked in the SGML world with a
component versioning system, we called it the "non-linear" design.

By going down this road, your table schema is static and can cope with
any type of DTD without change.  However, you need to create a tool that
will convert your XML document into a list of rows by mapping elements
in the DTD - you do this by allowing the user to define what level of
"componentisation" they want to achieve in the database i.e. the tags
that will be stored in database rows.
You could componentise everything (including ,  for HTML etc) but
this could produce thousands of rows for even quite a small document.
Maybe your XML docs are relatively clean and therefore don't have too
many layers, this would allow you to do the lot.

The next thing your tool needs to do, is to determine the parent-child
relationships between all the rows and express this using primary key
linking columns.  At this stage, you could also think about versioning -
our aim was to create a database that would allow editors to modify a
particular component by creating a copy of the row in the database,
linked to the same parents and children, but with a different version
number.  This means that he could choose to print the document with
certain revisions or at a certain version number.  

The tool also obviously needs to enable you to run queries that produce
"document" results, not just tag results, which would be easy.  As you
can imagine, rebuilding the relationships isn't a simple query - lots of
self correlation etc.

I was working on this SGML stuff in 1994, way before XML came along and
the tools we had to work with were primitive by modern standards
(Avalanche, Omnimark etc) - equally, when we worked with a document that
was moderately large, it required lots of database horsepower to make it
all work.  However, the holy grail of being able to create a true
SGML/XML repository that allows multi-user, concurrent, component level
editing/versioning was just within reach, if we could just get a Cray
(whatever happened to them?) to run it on!

Just in case you're wondering about possible applications for this,
think of people like Boeing and Airbus and how they manage and control
the editing of their sets of flight manuals etc.

Steve



-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of A. Pagaltzis
Sent: 05 May 2006 06:14
To: sqlite-users@sqlite.org
Subject: [RBL] Re: [sqlite] XML to SQLite upload

Hi Vivek,

* Rajan, Vivek K <[EMAIL PROTECTED]> [2006-05-05 06:40]:
> Sorry, I was not clear in my previous email. I do know the
> structure of the for the XML - I was wondering if there was a
> direct upload capability, once I know the structure of the XML. 

well, you can map generic XML to a relational database by storing
each syntactical element of the file in a row of a table,
together with information about how the elements are nested.
(Various ways to represent trees in a relational database exist.)
However, what you get is nearly useless for the kind of querying
that you typically want to do with a database.

Regards,
-- 
Aristotle Pagaltzis // 

[sqlite] RE: [RBL] RE: [sqlite] Writing wrappers?

[Steve O'Hara]

In most cases (but not all - C++,Delphi) yes.  A wrapper is a lump of C code 
that bridges the SQLite environment with your own specific language.

I just did a bit of research for you and found that Frontier uses a scripting 
language called UserTalk to allow users to interact with it.  It also only runs 
on Windows.

With this in mind, you will need to write a UserTalk extension as a DLL (C, C++ 
or Delphi) to agregate SQLite functionality into a small number of UserTalk 
verbs e.g. OpenDB, CloseDB and ExecuteDB perhaps.

Although I couldn't find it on the Frontier web site, I'm sure there is an 
extension specification defined somewhere.  I did notice that PostgreSQL has a 
Frontier extension - perhaps that would be a good starting point for some 
sample code http://spicynoodles.org/projects/postgresql/

Download the http://www.pivotal-solutions.co.uk/downloads/company/pssqlite.zip 
package for an example of C DLL (VC6) that provides bothe a VB and a Java 
interface with dynamic binding to 2.8.x and 3.x.x databases.  Just change the 
references to VB/Java specific stuff (data type conversions) and you're almost 
there.

Steve



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Gewirtz
Sent: 25 February 2006 05:03
To: sqlite-users@sqlite.org
Subject: [RBL] RE: [sqlite] Writing wrappers?

Thanks! So, being completely naïve, a wrapper's a chunk of C code, right?
It's not some kind of scripty interface into SQLite? So would the docs
really be the SQLite API, but with calls from the host language to the
SQLite API?

-- David

-Original Message-
From: Clay Dowling [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 24, 2006 10:07 AM
To: sqlite-users@sqlite.org
Subject: [RBL] Re: [sqlite] Writing wrappers?


David Gewirtz said:
>
> I've just started to explore SQLite and I've noticed a whole pile of 
> wrappers for various environments. The environment I'm using (the open 
> source Frontier Kernel) doesn't have any wrappers, so I'd like to 
> write one.
> Can someone post some pointers to resources on how to get started 
> writing wrappers?

As somebody who has written his own wrapper, the best advice I can give is
to see what the needs of your application are first.  Your wrapper class
effectively becomes the SQLite client program, so make sure that it
addresses all of the needs of SQLite such as statement finalization and
parameter population.  Make sure that the wrapper itself addresses the needs
of your program and makes it so that you don't need to make
sqlite3_* calls from your code.

It's definitely a good idea to be comfortable with writing a couple of C
programs that use SQLite first before trying to write a wrapper.  The
standard C interface to SQLite is pretty good already, and once you become
comfortable with it you'll be able to see what you want to do with your
wrapper.

Clay
--
Simple Content Management
http://www.ceamus.com

[sqlite] RE: [RBL] Re[2]: [sqlite] R: [sqlite] Snapshot database creation performance

[Steve O'Hara]

Hi Teg,

Presumably you have a transaction in place around the whole of your
inserts and that you have the PRAGMA synchronous = OFF; set.

Have you looked at perhaps not creating the database on the server, but
merely creating the INSERT statements in one big file that you compress
and send down to the client, who then decompresses and runs the inserts?
You could even abbreviate the insert statements but I've always found
(possibly because the indices don't compress well) that compressing the
source of a database gets you a much smaller payload than compressing
the finished database.

Steve


-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Teg
Sent: 07 February 2006 15:40
To: Andrew Piskorski
Subject: [RBL] Re[2]: [sqlite] R: [sqlite] Snapshot database creation
performance

Hello Andrew,

My purpose is primarily disk storage savings, the data's mainly text
so it's highly compressible. 500K on disk chunks of data decompress
out to about 8 megabytes of text. What compression scheme do they use?
I might consider trading some disk space for faster
compression/decompression.

C

Tuesday, February 7, 2006, 10:26:02 AM, you wrote:

AP> On Tue, Feb 07, 2006 at 08:51:43AM -0500, Teg wrote:

>> My application uses compressed data (gzip) but, the tradeoff to small
>> data files is exceptionally heavy CPU usage when the data is
>> decompressed/compressed.

AP> Incidentally, the MonetDB folks have done research on that sort of
AP> thing.  In their most recent project, "X100", they keep the data
AP> compressed both on disk AND in main memory, and decompress it only
in
AP> the CPU cache when actually manipulating values.

AP> They do that not primarily to save disk space, but to reduce the
AP> amount of memory bandwith needed.  Apparently in some cases it's a
big
AP> speed-up, and shifts the query from being memory I/O bound to CPU
AP> bound.  Of course, in order for that to work they have to use very
AP> lightweight compression/decompression algorithms.  Gzip gives much
AP> better compression, but in comparison it's extremely slow.

AP> Probably not immediately useful, but it seems like interesting
stuff:

AP>   http://monetdb.cwi.nl/
AP>   http://homepages.cwi.nl/~mk/MonetDB/
AP>   http://sourceforge.net/projects/monetdb/
AP>   http://homepages.cwi.nl/~boncz/

AP>   "MonetDB/X100 - A DBMS In The CPU Cache"
AP>   by Marcin Zukowski, Peter Boncz, Niels Nes, Sandor Himan
AP>   ftp://ftp.research.microsoft.com/pub/debull/A05june/issue1.htm

AP> Btw, apparently the current stable version of MonetDB is open source
AP> but they haven't decided whether the X100 work will be or not.

AP> Googling just now, there seems to have been a fair amount of
research
AP> and commercialization of this sort of stuff lately, e.g.:

AP>   http://db.csail.mit.edu/projects/cstore/




-- 
Best regards,
 Tegmailto:[EMAIL PROTECTED]

[sqlite] RE: [RBL] Re: [sqlite] ANN: SQLiteSpy 1.5.1 released

[Steve O'Hara]

Hi Ralf,

SqliteSpy is a nice tool but this is a weakness, not a strength - we
used to call this sort of thing "built-in obsolescence".  Woudn't it be
better for you if you didn't have to track changes made by Richard to
the engine?
This is also a problem with quite a few of the wrappers that embed the
engine.

Just a thought,

Steve


-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Ralf Junker
Sent: 03 February 2006 10:12
To: sqlite-users@sqlite.org
Subject: [RBL] Re: [sqlite] ANN: SQLiteSpy 1.5.1 released

Hello Joe Wilson,

the build-in database engine is a much praised feature of SQLiteSpy. It
simplifies the life of many users, and mine as well, since there can be
no incompatabilities with wrong DLLs and versions.

I am sorry that you can not use SQLiteSpy with your custom DLL. Maybe
you would like to contribute your changes to the SQLite sources, so they
can become part of SQLite and SQLiteSpy as well?

Apart from that, I monitor the development of SQLite closely and will
always update SQLiteSpy to the latest version of SQLite as quickly as
possible.

Regards,

Ralf

>I'm not sure if this is a good feature, though:
>
> Built in SQLite Engine
>SQLiteSpy comes as a single file executable with 
> the SQLite database engine already build into the 
> application. There is no need to distribute any DLLs, 
> which makes SQLiteSpy easy to deploy with customers.
>
>I have a custom sqlite3.dll so I would not be able 
>to use my databases with your app. Nor would your 
>users be able to upgrade to newer versions of 
>sqlite3.dll.

RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java

[Steve O'Hara]

You're right to a certain extent, but the point I was trying to address
was the ideal of being able to use an SQLite database from a variety of
toolsets and environments natively.  If you've ever written JNI you'll
know why this is a pain and a Java only implementation would be sweet.

Also, not all SQL engines work the same way and I'm certain HSQLD is
slower than SQLite architecturally, not because it's implemented in
Java.  After all, there is a non-free variant of HSQLDB  (HyperXtremSQL)
written in Java by the same author that is 50% faster - he didn't get
that by tweaking the code, more like re-architecting the storage.

The language is just a tool, a way of describing a solution to a
machine.  The judgement of performance etc of a language is a little
specious because it implies a generalisation of how the language is
implemented on a particular platform.  I've learned to like Java because
I've got a beautiful development environment (intelliJ IDEA) and in my
professional life, speed/quality of development is more important than
response times.  My clients would prefer to spend more money on hardware
than on consultancy - who can blame them.

Steve

-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Fred Williams
Sent: 21 January 2006 15:52
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java

I think if you will closely read you own analysis of your efforts you
will realize that all of the "down side" issues you have enumerated
relate directly to the implementation language and not the database or
its structure.  In Java there is no such thing as AnythingLite, IMHO.
Java, like so many other languages has grown well beyond its initial
intent, small, simple applets imbedded on a web page.

With all of our advances in programming we still have not evolved that
"perfect" language, and most likely never will.  I spite of what those
"C" guys tell you :-)

Fred

> -----Original Message-
> From: Steve O'Hara [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 21, 2006 7:37 AM
> To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
> Subject: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java
>
>
>
> I did loads of research on this and even tinkered with a c to Java
> converter, which got me a little bit further forward.  However, I
> realised that I would be facing a huge effort to create the code base
> and then have to support it within our projects.  So despite being an
> SQLite zealot, I had to reluctantly nail my colours to one of the
> existing Java tools.
>
> I chose HSQLDB, after trying out most of the others, this was the only
> one that got close to the file distribution format of SQLite i.e.
> database in a file.  It took quite a bit of tinkering to get the right
> mix of CACHED and MEMORY tables so that performance on start-up was
> good.  Also, I had terrible trouble with mass imports causing memory
> (what a surprise - Java) problems and it took a good few runs
> to get it
> to properly index etc.  Also, I had to be much more specific about the
> column definitions than with SQLite, otherwise my database files grew
> horribly.  Also, you can only interact with HSQLDB via JDBC, not a big
> problem in Java obviously.  Performance was nowhere near as good as
> SQLite.
>
> However, the upside is that HSQLDB is free, simple to deploy, has
> standalone/server/servlet/in-memory deployment versions and is
> reasonably perfomant.
>
> Hope this helps,
>
> Steve
>
> p.s. I'd still prefer a Java SQLite but there you are
>
>
>
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:sqlite-users-return-9982-sohara=pivotal-solutions.co.u
[EMAIL PROTECTED]
rg] On Behalf Of Ran
Sent: 19 January 2006 14:13
To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
Subject: [RBL] Re: [sqlite] Sqlite and Java

If I am not mistaken, the following thread might be relevant:
http://www.mail-archive.com/sqlite-users@sqlite.org/msg11005.html

Ran

On 1/19/06, Nilo Paim <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> Does anybody here knows something about a port of sqlite to java?
>
> Please, note that I'm not talking about java calling sqlite via JNI,
but
> about a real rewrite of sqlite using java. Obviously, a second step
> would be the writing of a JDBC driver.
>
> Would be useful that port?
>
> Comments? Suggestions?
>
> Thanks to all.
>
> Nilo
> Porto Alegre - Brasil
>

[sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java

[Steve O'Hara]

I did loads of research on this and even tinkered with a c to Java
converter, which got me a little bit further forward.  However, I
realised that I would be facing a huge effort to create the code base
and then have to support it within our projects.  So despite being an
SQLite zealot, I had to reluctantly nail my colours to one of the
existing Java tools.

I chose HSQLDB, after trying out most of the others, this was the only
one that got close to the file distribution format of SQLite i.e.
database in a file.  It took quite a bit of tinkering to get the right
mix of CACHED and MEMORY tables so that performance on start-up was
good.  Also, I had terrible trouble with mass imports causing memory
(what a surprise - Java) problems and it took a good few runs to get it
to properly index etc.  Also, I had to be much more specific about the
column definitions than with SQLite, otherwise my database files grew
horribly.  Also, you can only interact with HSQLDB via JDBC, not a big
problem in Java obviously.  Performance was nowhere near as good as
SQLite.

However, the upside is that HSQLDB is free, simple to deploy, has
standalone/server/servlet/in-memory deployment versions and is
reasonably perfomant.

Hope this helps,

Steve

p.s. I'd still prefer a Java SQLite but there you are

 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of Ran
Sent: 19 January 2006 14:13
To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
Subject: [RBL] Re: [sqlite] Sqlite and Java

If I am not mistaken, the following thread might be relevant:
http://www.mail-archive.com/sqlite-users@sqlite.org/msg11005.html

Ran

On 1/19/06, Nilo Paim <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> Does anybody here knows something about a port of sqlite to java?
>
> Please, note that I'm not talking about java calling sqlite via JNI,
but
> about a real rewrite of sqlite using java. Obviously, a second step
> would be the writing of a JDBC driver.
>
> Would be useful that port?
>
> Comments? Suggestions?
>
> Thanks to all.
>
> Nilo
> Porto Alegre - Brasil
>

[sqlite] RE: [RBL] Re: [sqlite] Randomly ordering results

[Steve O'Hara]

Jay, If you're going to offer advice, at least do some basic research to
make sure it's accurate.

Firstly, having a column that has a random number in it and sorting by
it produces the same output each time you query on it - obviously
unsatisfactory and I would have thought, manor from heaven for card
counters everywhere!!

Secondly, the standard SQLite function random() is actually seeded by
the current time and date every time you open a database.

Steve

p.s. Sorry, been down the pub.



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of Jay Sprenkle
Sent: 17 January 2006 14:09
To: sqlite-users@sqlite.org; Clark Christensen
Subject: [RBL] Re: [sqlite] Randomly ordering results

On 1/16/06, Clark Christensen <[EMAIL PROTECTED]> wrote:
>
> So, I have to ask, is this the right way to implement such
functionality?  Is there a better, or more efficient way?

The standard method of ordering a list randomly that doesn't return
duplicates
is to add a column for each of the items. Assign a random number to the
column.
The return the list sorted by the random number. It's used extensively
for shuffling
cards, etc.  You should be aware that the standard random number
functions
of most languages return the same sequence of results for the same
'seed' value.
So you generally have to do something like set the seed using the
current clock
so you get a different set of random numbers for each run of your
program.

[sqlite] RE: How to compile sqlite with VC6?

[Steve O'Hara]

There is a package in the SqliteWrappers WIKI to download that does all
this - 
http://www.pivotal-solutions.co.uk/downloads/company/pssqlite.zip

It's a nice VC6 DLL wrapper for VB6 & Java with source code.
Dynamically binds to the sqlite.dll and sqlite3.dll at runtime so you
don't need to recompile everytime a new sqlite version comes along (why
aren't all the wrappers like this???)

I've inlcuded the Java wrapper classes with test code and also the VB6
test code.  The JNI implementation returns proper native Java types has
also been tested on Linux as a shared library.

It has been used for ages on various projects here - do what you want
with it even if it just serves as some sample code for you.

Steve




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of Michael Sizaki
Sent: 07 January 2006 01:44
To: sqlite-users@sqlite.org
Subject: [RBL] [sqlite] How to compile sqlite with VC6?

Hi,

I want to use sqlite from java on windows. I want to create my own
jni binding (different from
http://www.ch-werner.de/javasqlite/overview-summary.html).

I have VC6 but I'm not a C programmer. How to compile sqlite?
Essentially I would like to add a few simple functions to sqlite
written in C

Michael

[sqlite] RE: [RBL] [sqlite] JDBC driver

[Steve O'Hara]

Just a word of advice, make your binding to SQLite dynamic - it's more
code but ultimately you won't have to keep releasing new versions of
your driver everytime SQLite changes.

Steve

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of gnorman22
Sent: 31 December 2005 22:38
To: sqlite-users@sqlite.org
Subject: [RBL] [sqlite] JDBC driver

I've been working on a JDBC driver for the latest version of Sqlite
(3.2.8).  I know that someone has already written 1 for an older
version, and I really didn't intend to reinvent the wheel.  However, I
wanted to learn Sqlite and how to write a JDBC driver and this sort of
evolved.  If this is this something that anyone would be interested in
looking at, I'd be happy to share what I have.  

Let me know.

RE: [sqlite] SQLite as a Windows kernel tool

[Steve O'Hara]

Fred,

They are not nit-picking and they "are" actually contributing to the
robustness of the application by doing this research.  Your
anti-Microsoft bigotry does no service to this list at all and is
neither a "contribution" or an offer of help.

I for one would be keen to see these warnings addressed and I agree with
the point made by the original contributor, I'm not familiar enough with
the code to be able to make any sensible changes.  I would be happy to
help in any way I can - all my clients are Windows or Solaris and
warnings appear on both of these platforms.

Steve


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of Fred Williams
Sent: 31 October 2005 05:19
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] SQLite as a Windows kernel tool

Look I'm certain you mean well, but the rest of us are pretty busy using
one of the best small footprint databases on the planet.  That means we
are way too busy to nit-pic a good product to pieces, just because it
won't compile clean using Mickeysoft's latest and greatest.

How' bout you go through this buggy code and fix all your concerns then
upload it to CVS.  That way you would be making a huge contribution to
us all, and won't come off as such an irritating whiner.

Fred

> -Original Message-
> From: Dirk Zabel [mailto:[EMAIL PROTECTED]
> Sent: Sunday, October 30, 2005 3:59 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] SQLite as a Windows kernel tool
>
>
> [EMAIL PROTECTED] schrieb:
>
> >Ken & Deb Allen <[EMAIL PROTECTED]> wrote:
> >
> >
> >>vdbeapi.c
> >>e:\SQLITE\327\Source\vdbeapi.c(55) : warning C4244: 'return' :
> >>conversion from 'i64' to 'int', possible loss of data
> >>e:\SQLITE\327\Source\vdbeapi.c(195) : warning C4244: '=' :
> conversion
> >>from 'double' to 'i64', possible loss of data
> >>e:\SQLITE\327\Source\vdbeapi.c(232) : warning C4244: '=' :
> conversion
> >>from 'double' to 'u64', possible loss of data
> >>
> >>
> >>
> >
> >What about these three warnings do you think is a concern?
> >Have you actually looked at the code in question to see
> >if the possibility of data loss is real and unintentional?
> >What makes you think that these warnings are not just a case
> >of the compiler blowing smoke?
> >
> >--
> >D. Richard Hipp <[EMAIL PROTECTED]>
> >
> >
> >
> >
> These concerns seem to me not unfounded.
> Just looking at the three cited positions in vdbeapi.c, i find:
> Line 55: the conversion i64->int might be ok, depends on the
> runtime-argument pVal. I am not sure.
> Line 195:  this  conversion  double->i64  is done by intent;
> giving the
> number of nanoseconds since midnight. I think a
> cast to int64 would be appropriate to express this intent. I comment
> might help to see the reason, but on the other hand the code
> looks quite
> obvious here.
> Line 232: same conversion, insofar applies the same remark.
> But what if
> between the computation of startTime and rNow midnight
> occurred? I guess
> there would be a wrap-around - an error in my point of view.
>
> I don't think it's a good idea to assume a compiler warning
> about type
> conversions are "blowing smoke". At least, they should be
> eliminated in
> order not to cover messages about real quirks.
>
> Regards
>   Dirk
>

RE: [sqlite] Convert SQLite to Java

[Steve O'Hara]

As I mentioned in my question, I have already written a JNI library for
Windows and Solaris for SQLite they work fine.  And no Jay, you can't
"link" DLLs/Shared Libraries into Java, you can bind to them via a JNI
container.

The attraction of a pure Java solution is obvious - if a client wants
this app to run on VMS then I've got to create another JNI library that
is VMS specific.  Id you've ever written any JNI you'll know why this
isn't an all together pleasurable experience.

I've tried the C2J application and that actually looks like it does a
reasonbale job but with a whole load of missing stuff, mainly in pager.c
I'll have another crack at it when I get a bit more time.

Steve



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of Andrew Piskorski
Sent: 24 October 2005 22:21
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Convert SQLite to Java

On Mon, Oct 24, 2005 at 09:58:53PM +0100, Steve O'Hara wrote:

> I've been worn down by my quest for a comparable product to SQLite
> written in pure Java and have come to the conclusion that it doesn't
> exit.  I've looked at Derby, QED, Axion, blah blah and I'm not too

> My next port of call is to look at the feasibility of converting the
> SQLite source into Java!  

Uh, why isn't your first choice simply, "Use SQLite from Java"?
Surely calling C libraries is something the Java folks have worked out
how to do many years ago?  Or what am I missing here?  What is the
attraction of "pure Java"?

-- 
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com/

[sqlite] Convert SQLite to Java

[Steve O'Hara]

I have used SQLite in a whole bundle of applications and I love it.
However, I've got an app that's being written in Java -  I've got a JNI
library (Solaris & Windows) for SQLite, but I really want something
platform independent.

I've been worn down by my quest for a comparable product to SQLite
written in pure Java and have come to the conclusion that it doesn't
exit.  I've looked at Derby, QED, Axion, blah blah and I'm not too
impressed by any of them.
None of them are as good as SQLite and they all use multiple files for
their storage.

My next port of call is to look at the feasibility of converting the
SQLite source into Java!  
I'd like to know whether a) anyone has tried this before, b) what might
be the pitfalls and c) am I being completely mental in even thinking
about trying this?

Steve




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of Martin Engelschalk
Sent: 24 October 2005 20:32
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] glibc detected...

Hi,

As Christian said, probably your heap is corrupted. Your backtrace 
clearly indicates that.
The typical errors that lead to this are
- you free() some memory twice
- you free more or less memory than you malloc() ed
- you overrun a buffer on the heap

valgrind is a good tool to detect such mistakes.

Martin

[EMAIL PROTECTED] schrieb:

>tanx for the advice...but how to avoid heap corruption? and why does it
happen?
>anyway, finally here is the backtrace:
>
>*** glibc detected *** malloc(): memory corruption: 0x0808e078 ***
>
>Program received signal SIGABRT, Aborted.
>[Switching to Thread -1213548864 (LWP 4348)]
>0xe410 in __kernel_vsyscall ()
>(gdb) ba
>#0  0xe410 in __kernel_vsyscall ()
>#1  0x4fad57d5 in raise () from /lib/tls/libc.so.6
>#2  0x4fad7149 in abort () from /lib/tls/libc.so.6
>#3  0x4fb0927a in __libc_message () from /lib/tls/libc.so.6
>#4  0x4fb1049c in _int_malloc () from /lib/tls/libc.so.6
>#5  0x4fb11f01 in malloc () from /lib/tls/libc.so.6
>#6  0xb7d95c03 in sqlite3Malloc (n=-16) at ./src/util.c:296
>#7  0xb7d885f2 in sqlite3ParserAlloc (
>mallocProc=0xb7d95bdc ) at parse.c:1302
>#8  0xb7d9382d in sqlite3RunParser (pParse=0xb550,
>zSql=0x8093c38 "SELECT subjNum FROM \"images\" WHERE id==15;",
>pzErrMsg=0xb54c) at ./src/tokenize.c:349
>#9  0xb7d8c777 in sqlite3_prepare (db=0x808d5d0,
>zSql=0x8093c38 "SELECT subjNum FROM \"images\" WHERE id==15;",
>nBytes=-1, ppStmt=0xb648, pzTail=0x0) at ./src/prepare.c:440
>#10 0x0804d0ef in subjId (db=0x808d5d0, id=15, subj=0xb748,
>test=0x0) at database.c:901
>#11 0x0804e8f8 in featVect (db=0x808d5d0, recog_id=1, maxEigen=0)
>at database.c:1662
>#12 0x0804a26a in main (argc=5, argv=0xb864) at main.c:400
>(gdb)
>
>I also noticed that error occours even if the requested row id is every
time
>the same!
>So the problem occours after a certain number of iterations.
>The code to read is something like this:
>
>sqlite3_stmt *pStmt=0;
>   char *sql=0;
>   int sql_error=0;
>   
>   asprintf(, "SELECT subjNum FROM \"images\" WHERE id==%d;"
id);
>   if ( !sqlite3_prepare(db, sql, -1, , 0) )
>   {
>   if (sqlite3_step(pStmt)==SQLITE_ROW)
>   {
>   test = (char*) sqlite3_column_text (pStmt,0);
>   }
>   else
>   {
>   fprintf(stderr,"\nWARNING: No image associated
to requested id\n");
>   sql_error = 1;
>   }
>   }
>   else
>   {
>   fprintf(stderr, "\nERROR: SQL prepare error:\n\t%s\n",
sqlite3_errmsg(db));
>   sql_error=1;
>   }
>   
>   if ( sqlite3_finalize(pStmt) != SQLITE_OK )
>   {
>   fprintf(stderr, "\nERROR: SQL finalization
error:\n\t%s\n", sqlite3_errmsg(db));
>   sql_error=1;
>   }
>   
>   free(sql);
>   
>   if (sql_error)
>   {
>   sqlite3_close (db);
>   exit(1);
>   }
>
>it is inside a function that is called iteratively from another
function,
>incrementing the passed id num
>tanks
>
>__
>TISCALI ADSL
>Solo con Tiscali Adsl navighi senza limiti e telefoni senza canone 
>Telecom a partire da 19,95 Euro/mese.
>Attivala subito, I PRIMI DUE MESI SONO GRATIS! CLICCA QUI:
>http://abbonati.tiscali.it/adsl/sa/1e25flat_tc/
>
>
>
>  
>

RE: [sqlite] Upcoming Conferences

[Steve O'Hara]

Hey, why not use the SQLite based spellchecker at
http://www.pivotal-solutions.co.uk/spellcheck/

I know it says it's for sale but we're going to start giving it away in
the next few weeks.

Steve 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of [EMAIL PROTECTED]
Sent: 10 October 2005 15:37
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Upcoming Conferences

Dan Kennedy <[EMAIL PROTECTED]> wrote:
> > 
> > Yes.  I appologize for the misspelling.  And, No, I was not
> > aware of the second Frankfurt.  Frankfurt am Main is the only
> > one I had ever heard of.
> 
> How about "Sidney" then? We're offended too! :)
> 

If you haven't noticed already, spelling is not something
I am especially good at.  :-)

Clearly I need to add a spell checker to my home-grown
email client...

--
D. Richard Hipp <[EMAIL PROTECTED]>

RE: [sqlite] Speed Test Done !

[Steve O'Hara]

Your speed comparison is deeply flawed...

Your select statement is non-sensical (it returns 2 columns, A and
'32.0883' with 9,337,681 records and you haven't told us if you're using
PRAGMA synchronous = OFF;?
Assuming you do a proper search like "select * from T where
A='32.0883';" you should make sure A is indexed.

Try this and come back to us with the results:-

sqlite3 test2.db
create Table T (A, B, C );
PRAGMA synchronous = OFF;
.separator ,
.import 'sqtest2.txt' T
create index TA on T(A);
select * from T where A='32.0883';

Steve
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of Richard
Sent: 06 October 2005 04:57
To: SQLite Users Mailing List
Subject: [sqlite] Speed Test Done !
Importance: High

Well, finally import 9,337,681 records into sqlite3 test2.db
and ran the test.


import sqtest4.txt : 2 min 28 seconds
select A, '32.0833' From T ; 9 min 20 seconds
--


I use another database for MacOS X
also works on Windows, Call Panorama

Did another test, comparing database...

import sqtest4.txt : 36 seconds
select from Field A contains 32.0833 / 55 seconds found 4322 records
out of 9,337,681

Still have found no sql program yet, that can beat Panorama in speed.

Regards-
Richard Nagle
CMS

RE: [sqlite] Data Manipulation ?

[Steve O'Hara]

Here's a  way to go with pure SQL;

create table cars (recid,qty,make,model,year,engine,color,state,price);
create table states (abbr,name);

insert into states values("ca","California");
insert into cars values(1,5,"Ford","Bandit",2005,2000,"Red","ca",5000);

select make,(select name from states where abbr=state) as statename from
cars;

Steve




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of Richard Nagle
Sent: 26 September 2005 04:14
To: sqlite-users@sqlite.org
Subject: [sqlite] Data Manipulation ?

Does SQLite support any direct built-in commands, that can
manipulate data?

ie.
suppose the boss wanted a report of cars honda in CA,
but he wants to see the California instead of CA,
so you need to convert all the state fields into full names,
how would this be done...

Fields are as follows:

recid
qty
make
model
year
engine
color
state
price


Thanks -
Richard

-- 

I will not be pushed, filed, stamped, indexed, briefed, debriefed, or 
numbered!
My life is my own - No. 6

RE: [sqlite] Intro SQL ?

[Steve O'Hara]

Richard,

Not everything in life is free or immediate.

If you're going to do some decent SQL you need to invest in a reference
manual - my favourite SQL primer is "The Practical SQL Handbook" from
Addison-Wesley Publishing ISBN 0-201-62623-3 
My edition is acient but well worth the 20 quid I paid for it.

Steve

"To learn something, you need a book - to know something, you need to
try and teach it!"


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of Richard Nagle
Sent: 14 September 2005 06:56
To: sqlite-users@sqlite.org
Subject: [sqlite] Intro SQL ?

Well, now I ready for the next step,
looking for a intro into SQL...

been searching google all night, found hundreds of sites,
that start off with a table, but nothing showing, how to create
a database, and place it in a directory, or in the same folder,
with the sql application.

Looking for a intro, that would show commands, to list
databases & tables that you just created... or allow you to see,
into other folders.

Again, looking for the intro to the intro of SQL.
where we start with the very basic of basic.

So, does anyone have a few links...

Major Thanks -
Rick

RE: [sqlite] Index and General Optimization Question

[Steve O'Hara]

Why don't you create and a very small version of the database, create the
indices and use the EXPLAIN command to see what it does for your queries.

Steve

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg]On Behalf Of John Sample
Sent: 12 August 2005 16:18
To: sqlite-users@sqlite.org
Subject: [sqlite] Index and General Optimization Question


Hello all.
I'm a new Sqlite user porting a large db for an open source project
from SQL Server.

I have a question regarding whether an index makes sense or will be
used for a certain scenario. Since the table in question is so large
it takes up to 8 hours for me to create new indexes, so I'd like to
see if I can get a best guess before trying.

A little background info:
This is for a GIS system. The Sqlite database is 2+ gigs at the moment.
The table in question has 17,000,000 rows and is performing well so far.
It has a multicolumn index on 4 columns which are always part of the
queries.

NAME TYPE DIRP DIRS

There are 2 more columns that make up the rest of the select clause,
but it is an OR statement. A pseudo select clause would look like
this:

NAME='char' and TYPE='char' DIRP='char' DIRS='char' and (ZIPL =int OR
ZIPR=int)

Now to the question:
Can/will a multicolumn index (ZIPL,ZIPR) be used for an OR clause?
If so, what if it was part of the other multicolumn index?

Thanks for any guidance!

RE: [sqlite] sqlite with visual basic?

[Steve O'Hara]

Check out the WIKI, there's a myriad of possibilities.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg]On Behalf Of Scott Chapman
Sent: 11 August 2005 18:43
To: sqlite-users@sqlite.org
Subject: [sqlite] sqlite with visual basic?


I am having a look at Visual Basic Express 2005 Beta.  I haven't 
programmed VB since version 3.0 on Windows 3.1 many years ago.  I didn't 
do any database with it then.

All of my programming these days is in Python with Postgresql or SQLite.

Has anyone gotten VB and SQLite working together?

Are there some examples of this available?

Scott

RE: AW: [sqlite] VB6 question

[Steve O'Hara]

How does a C++ wrapper help someone using VB6?

Steve

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg]On Behalf Of RAY BORROR
Sent: 29 July 2005 05:22
To: sqlite-users@sqlite.org
Subject: Re: AW: [sqlite] VB6 question


I am using SQLite Plus sucessfully

Ray Borror

Gregory Letellier <[EMAIL PROTECTED]> wrote:
all the wrapper ar for 2.8 and i wan't use the 3.0
anyone known 3.0 wrapper ?

Steve O'Hara a écrit :

>Don't want to dampen your enthusiasm for this route but. why do you
>think there are so many VB wrappers for SQLite?
>
>It's because you can't use the SQLite DLL directly from VB - some functions
>will work but the essential ones won't. It's because the DLL returns things
>like pointers to arrays of pointers which is not very groovy in VB (in
fact,
>you would have to resort to some OS calls to unravel that).
>
>Use one of the wrappers.
>
>Steve
>
>
>
>
>
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]
>rg]On Behalf Of Gregory Letellier
>Sent: 27 July 2005 11:17
>To: sqlite-users@sqlite.org
>Subject: Re: AW: [sqlite] VB6 question
>
>
>Ok Thank's for your help i will trying this !!!
>
>[EMAIL PROTECTED] a écrit :
>
>
>
>>Hi,
>>
>>unfortunately this has to do with the C calling convention used by
>>
>>
>sqlite3.dll. By default DLLs compiled with C have the cdecl calling
>convention, but VB only supports the stdcall calling convention.
>
>
>>You must recompile sqlite using MS Visual C++ or other compiler and switch
>>
>>
>the default calling convention from cdecl to stdcall in the compiler/linker
>settings.
>
>
>>HTH
>>Michael
>>
>>
>>
>>
>>
>>>hello i'm trying to open a database with VB6 without wrapper
>>>
>>>i'm using sqlite3.dll
>>>
>>>and it's my code :
>>>
>>>Option Explicit
>>>Private Declare Function sqlite3_open Lib "sqlite3.dll" (ByVal filename
>>>As String, ByRef dbHandle As Long) As Long
>>>Private Declare Function sqlite3_open16 Lib "sqlite3.dll" (ByVal
>>>filename As String, ByRef dbHandle As Long) As Long
>>>Private Declare Sub sqlite3_close Lib "sqlite3.dll" (ByVal DB_Handle As
>>>Long)
>>>
>>>Private Sub Form_Load()
>>> Dim lRet As Long
>>> Dim lDbHandle As Long
>>> Dim sFilename As String
>>>
>>> sFilename = "c:\toto.db"
>>> sqlite3_open sFilename, lDbHandle
>>> MsgBox ("lRet=" & lRet)
>>> MsgBox ("ldbhandle=" & lDbHandle)
>>> sqlite3_close (lDbHandle)
>>>End Sub
>>>
>>>when i launch it, i've an error 49 : Bad DLL calling convention
>>>
>>>anyone can help me ? where is my fault ?
>>>
>>>thx
>>>Gregory Letellier
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
>
>
>

RE: AW: [sqlite] VB6 question

[Steve O'Hara]

Attached (now in the WIKI) is a VB6 wrapper that is a bit different to most
in that it binds to the sqlite DLL at runtime.

Consequently, all you need to do is put this in your path along with the
sqlite3.dll (or sqlite.dll if you want to use 2.8.x) and it sorts out the
calls at runtime.

The DLL also contains a Java JNI implementation that does the same thing.
As with the VB6, you can call it from Java without having to worry about
re-creating the DLL for each new release of sqlite.

The zip contains VB6 and Java examples.

As with sqlite, it's free and if you want the source code for the DLL I'll
send it anyone that's interested.

Steve



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg]On Behalf Of Gregory Letellier
Sent: 28 July 2005 13:02
To: sqlite-users@sqlite.org
Subject: Re: AW: [sqlite] VB6 question


all the wrapper ar for 2.8 and i wan't use the 3.0
anyone known 3.0 wrapper ?

Steve O'Hara a écrit :

>Don't want to dampen your enthusiasm for this route but. why do you
>think there are so many VB wrappers for SQLite?
>
>It's because you can't use the SQLite DLL directly from VB - some functions
>will work but the essential ones won't.  It's because the DLL returns
things
>like pointers to arrays of pointers which is not very groovy in VB (in
fact,
>you would have to resort to some OS calls to unravel that).
>
>Use one of the wrappers.
>
>Steve
>
>
>
>
>
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]
>rg]On Behalf Of Gregory Letellier
>Sent: 27 July 2005 11:17
>To: sqlite-users@sqlite.org
>Subject: Re: AW: [sqlite] VB6 question
>
>
>Ok Thank's for your help i will trying this !!!
>
>[EMAIL PROTECTED] a écrit :
>
>
>
>>Hi,
>>
>>unfortunately this has to do with the C calling convention used by
>>
>>
>sqlite3.dll. By default DLLs compiled with C have the cdecl calling
>convention, but VB only supports the stdcall calling convention.
>
>
>>You must recompile sqlite using MS Visual C++ or other compiler and switch
>>
>>
>the default calling convention from cdecl to stdcall in the compiler/linker
>settings.
>
>
>>HTH
>>Michael
>>
>>
>>
>>
>>
>>>hello i'm trying to open a database with VB6 without wrapper
>>>
>>>i'm using sqlite3.dll
>>>
>>>and it's my code :
>>>
>>>Option Explicit
>>>Private Declare Function sqlite3_open Lib "sqlite3.dll" (ByVal filename
>>>As String, ByRef dbHandle As Long) As Long
>>>Private Declare Function sqlite3_open16 Lib "sqlite3.dll" (ByVal
>>>filename As String, ByRef dbHandle As Long) As Long
>>>Private Declare Sub sqlite3_close Lib "sqlite3.dll" (ByVal DB_Handle As
>>>Long)
>>>
>>>Private Sub Form_Load()
>>>  Dim lRet As Long
>>>  Dim lDbHandle As Long
>>>  Dim sFilename As String
>>>
>>>  sFilename = "c:\toto.db"
>>>  sqlite3_open sFilename, lDbHandle
>>>  MsgBox ("lRet=" & lRet)
>>>  MsgBox ("ldbhandle=" & lDbHandle)
>>>  sqlite3_close (lDbHandle)
>>>End Sub
>>>
>>>when i launch it, i've an error 49 : Bad DLL calling convention
>>>
>>>anyone can help me ? where is my fault ?
>>>
>>>thx
>>>Gregory Letellier
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
>
>
>

RE: AW: [sqlite] VB6 question

[Steve O'Hara]

Don't want to dampen your enthusiasm for this route but. why do you
think there are so many VB wrappers for SQLite?

It's because you can't use the SQLite DLL directly from VB - some functions
will work but the essential ones won't.  It's because the DLL returns things
like pointers to arrays of pointers which is not very groovy in VB (in fact,
you would have to resort to some OS calls to unravel that).

Use one of the wrappers.

Steve






-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg]On Behalf Of Gregory Letellier
Sent: 27 July 2005 11:17
To: sqlite-users@sqlite.org
Subject: Re: AW: [sqlite] VB6 question


Ok Thank's for your help i will trying this !!!

[EMAIL PROTECTED] a écrit :

>Hi,
>
>unfortunately this has to do with the C calling convention used by
sqlite3.dll. By default DLLs compiled with C have the cdecl calling
convention, but VB only supports the stdcall calling convention.
>
>You must recompile sqlite using MS Visual C++ or other compiler and switch
the default calling convention from cdecl to stdcall in the compiler/linker
settings.
>
>HTH
>Michael
>
>
>
>>hello i'm trying to open a database with VB6 without wrapper
>>
>>i'm using sqlite3.dll
>>
>>and it's my code :
>>
>>Option Explicit
>>Private Declare Function sqlite3_open Lib "sqlite3.dll" (ByVal filename
>>As String, ByRef dbHandle As Long) As Long
>>Private Declare Function sqlite3_open16 Lib "sqlite3.dll" (ByVal
>>filename As String, ByRef dbHandle As Long) As Long
>>Private Declare Sub sqlite3_close Lib "sqlite3.dll" (ByVal DB_Handle As
>>Long)
>>
>>Private Sub Form_Load()
>>   Dim lRet As Long
>>   Dim lDbHandle As Long
>>   Dim sFilename As String
>>
>>   sFilename = "c:\toto.db"
>>   sqlite3_open sFilename, lDbHandle
>>   MsgBox ("lRet=" & lRet)
>>   MsgBox ("ldbhandle=" & lDbHandle)
>>   sqlite3_close (lDbHandle)
>>End Sub
>>
>>when i launch it, i've an error 49 : Bad DLL calling convention
>>
>>anyone can help me ? where is my fault ?
>>
>>thx
>>Gregory Letellier
>>
>>
>>
>>
>
>
>
>

RE: [sqlite] Multi-threading.

[Steve O'Hara]

I think the point about multi-threaded apps is not that there might be a few
instances where they are useful, but how easy is it to debug and support
them and is it worth the price for a little more concurrency?

In my experience, most debugging IDE's can't handle multiple threads and
actually turn the application into a pseudo threaded version prior to
running it.  I wouldn't mind betting that's what's going on in Java (it's
worth pointing out that Java didn't used to even support native threads and
I bet most Java programmers have no idea whether they are actually using
Native or pseudo threads)

Because of this, you get the frustrating situation where an application
works fine in debug but fails sporadically in production.  Another good real
world example of this is the IIS/ASP server side debugging.  IIS allocates a
new thread per request which are autonomous but do some semaphoring to share
the Session object (I think).  There's a handy switch you can set on your
IIS virtual directory that turns on server side debugging - great! .
only, not so great!! Suddenly IIS starts allocating the same thread to every
request i.e. it queues your requests and the very problem you were trying to
solve goes away!

The moral of the story is as Richard says, if there isn't a burning need for
multiple threads then don't use them.

By the way, Mrs Brisby is being facetious when he says that he doesn't
regard Windows as a "modern" GUI - there's no such thing!  They've all got
their origins in concepts put forward over 20 years ago.

Steve


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg]On Behalf Of Ben Clewett
Sent: 25 July 2005 09:01
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Multi-threading.


Dear Mrs Brisby,

Thanks for your passionate replies to my original posting.  You have
much information here.  It's obvious I don't know everything about
threading.

I like what you say about computer science being a Science.  This is
exactly my point.  A science is a collection of theories which hold true
within a domain until otherwise dissproven.  For instance Isac Newtons's
law of gravety and Einstain's law.  Both are true within a fixed domain.
  Both are used today.  Neither are truelly corrrect.  There will be
another more complex theroy in time.

This is the same with Threading.  There may be places where this is
useful.  There may be places where it should not be used.  Both are
theories within computer science which hold true in a limited domain.
So when I said this was my opinion, I should have stated this is my
theory within a fixed domain.  However when you stated that I was wrong,
I don't think this is compatible of your statement that Computer Science
is a Science.  Nothing in any science is either right or wrong.  That's
a Religion.

I don't want to spend ages on the argument, I can see there are
passionate views.  I only want to explore the idea that threading is a
viable strategy for a modern high level language and can produce stable
applications with low development time.

For instance a call to a TCP blocking Wait.  It's perfectly possible for
one thread to cycle round handing GUI events, then checking on the port
for new packets.

But an alternate method is to partition the code space into two
autonomous threads using their own variable set.  Two simple sets of
code which are not coupled, and remain highly cohesive and encapsulated.
  Communicating through a thread-safe object.  Such code is fast to
write, easy to read, robust and does the job.  I can complete this in c#
in ten minutes, and it will not break.  With large amounts of time,
better methods may be available.  But this theory is viable within its
domain.

 > I wasn't about to consider Windows a modern GUI system :)

Are you saying it's not modern, or not a GUI?  It may not be prefect and
it is very complex.  But it's not about to go away, and it's installed
on modern computers.  More importantly, my views on threads remain.  If
you give the GUI it's own thread, you have implemented a simple solution
to ensure that the correct cursor and mouse events are honoured.  Then a
worker thread is free to do what ever it likes without being coupled to
the GUI.  Simple robust coding using thread-safe objects.

I am also interested in peoples views that threading is slower.  Since
all processors are likely to be hyperthreaded, multicore, or both.  I
can see no place where this will be true in the future.

 > Java uses references, not pointers.

Is there any important difference?  My point was not about language.  It
was a question to Dr Hipp about what he feels is missing from the Java
pointer (reference) model.  Perhaps I should have explained better.

Yes, I understand that 'c' can make use of goto, and that goto is fast.
  There are also very very bad places to use goto.  Exceptions, breaks
and continue statements are linear code, easy to follow and more robust
to code changes.  Goto is a legacy of assembler 

RE: [sqlite] Possible enhancement to SQL logic

[Steve O'Hara]

Is that statement correct Richard?
I assumed that something clever was going on with OR's such that under the
bonnet they got translated into UNION statements or similar.

Steve

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg]On Behalf Of Dan Kennedy
Sent: 11 July 2005 11:49
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Possible enhancement to SQL logic



Won't work unfortunately. Currently indices are never used if
the WHERE clause has an OR expression in it.

--- Aaron Burghardt <[EMAIL PROTECTED]> wrote:

> Try adding another index:
>
> CREATE INDEX a_f1_f2 ON a (f1, f2);
>
> Does that help?
>
> Aaron Burghardt
>
> On Jul 11, 2005, at 6:07 AM, Ben Clewett wrote:
>
>
> > Dear SQLite,
> >
> > I have found a possible area where the SQL logic of SQLite is not
> > as good as other DBMS.  Like MySQL or PostgreSQL.  It's a simple
> > thing, so I am showing it as a candidate for work.  (If I could
> > submit a patch I would :)
> >
> > If you create a table with two indexes:
> >
> > CREATE TABLE a (
> > f0 INTEGER PRIMARY KEY,
> > f1 INTEGER,
> > f2 INTEGER
> > );
> > CREATE INDEX a_f1 ON a (f1);
> > CREATE INDEX a_f2 ON a (f2);
> >
> > Now execute a query using both the indexes:
> >
> > SELECT * FROM a WHERE f1 = 1 OR f2 = 1;
> >
> > This query will not use the indexes.  The query will increment
> > through every row in the table.  This is obviously very slow.
> >
> > As I mensioned, MySQL and PostgreSQL will use the indexes here, and
> > therefore return the result considerably faster.
> >
> > I can use the 'UNION' to get the result I am after, so it's not a
> > show stopper.
> >
> > I hope this is of interest to somebody.
> >
> > Regards,
> >
> > Ben Clewett.
> >
> >
> >
> >
> >
> >
>
>
>





Sell on Yahoo! Auctions – no fees. Bid on great items.
http://auctions.yahoo.com/

RE: [sqlite] Does SQLite have a fulltext search like MySQL?

[Steve O'Hara]

It's written in C already... MS VS 6

Steve

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg]On Behalf Of Jay Sprenkle
Sent: 06 July 2005 16:31
To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
Subject: Re: [sqlite] Does SQLite have a fulltext search like MySQL?


On 7/6/05, Steve O'Hara <[EMAIL PROTECTED]> wrote:
>
> SQLite doesn't have a free text search capability - the Like and Glob
> functions are not free text just simple pattern matching on the scanned
> text.  Performance is very poor because there is no suitable index.
>
> It's not a simple task to create free text searching - you have to create
an
> inverted index for every (or all) columns you want to search on, then you
> have to find a mechanism to combine that in the SQL parser.  The inverted
> index means creating a grammar parser and a language specific stemmer to
> produce terms with their associated proximity info.  The same
parser/stemmer
> is then used to produce your search terms from the SQL statement.
>
> I've been creating such a beast for a while with some nice results.  The
> project stems from an idea of creating published DVD searchable databases
of
> library content, but I haven't worked on it for ages.
>
> I was hoping to get it to a point where I could offer it up to the SQLite
> community as a side project for development as an add-in to the core code.
> At the moment, it's got a VB front end to a VS6.0 DLL but the idea is to
> make it an extension of the sqlite3.exe.
>
> Is there anyone out there that would like to get involved in this?  If
there
> is, I'll happily provide a precise of how it works, what's been done and
> what there is still to do.

What is the dll written in? It might be easy to port to C as source
others can include in their programs as a user defined function.

RE: [sqlite] Does SQLite have a fulltext search like MySQL?

[Steve O'Hara]

SQLite doesn't have a free text search capability - the Like and Glob
functions are not free text just simple pattern matching on the scanned
text.  Performance is very poor because there is no suitable index.

It's not a simple task to create free text searching - you have to create an
inverted index for every (or all) columns you want to search on, then you
have to find a mechanism to combine that in the SQL parser.  The inverted
index means creating a grammar parser and a language specific stemmer to
produce terms with their associated proximity info.  The same parser/stemmer
is then used to produce your search terms from the SQL statement.

I've been creating such a beast for a while with some nice results.  The
project stems from an idea of creating published DVD searchable databases of
library content, but I haven't worked on it for ages.

I was hoping to get it to a point where I could offer it up to the SQLite
community as a side project for development as an add-in to the core code.
At the moment, it's got a VB front end to a VS6.0 DLL but the idea is to
make it an extension of the sqlite3.exe.

Is there anyone out there that would like to get involved in this?  If there
is, I'll happily provide a precise of how it works, what's been done and
what there is still to do.

Steve



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg]On Behalf Of Jim Dodgen
Sent: 06 July 2005 03:48
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Does SQLite have a fulltext search like MySQL?


look at the glob command it works like like except uses the unix file name
globbing style of matching
not quite a grep

select * from table where a glob '[abc]foobar*';

At 06:47 PM 7/5/2005, you wrote:
>>like this?
>>select * from table where a like '%abc%';
>
>SQLite also makes it easy to write your own functions.  That way you
>can define other matching algorithms (eg Jaro-Winkler).
>
>Roger

RE: [sqlite] Insert all rows from old table into new table but in sorted order

[Steve O'Hara]

Some databases do actually allow you to maintain an insertion order.

They do this for performance reasons so that the high cost of sorting is
avoided - we have a few newspaper databases (>30 million full text stories)
that have their primary key defined as the inverse story insertion date -
this means that when a journalist searches for a story, they always get the
results in 'latest first' order, which is nearly always what they want.

Typically, a journalist will run searches that return 10's of thousands of
results, multiply that by the number of users within the paper (could be
hundreds worldwide) and you can begin to see why this 'pre-sorting' of
results is very useful.

It's a little acedemic to say that a database should not store its data in a
particular way, in a similar way to saying that all data MUST be normalised.
In the real world, where performance is maybe more important than storage
space, imposing a scheme on the data can be very important.

Steve


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg]On Behalf Of Puneet Kishor
Sent: 30 June 2005 14:09
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Insert all rows from old table into new table but
in sorted order



On Jun 30, 2005, at 7:21 AM, Ajay wrote:

>
> Yaa that's what I wanted to do , So what do you think what could be the
> solution for this ?

well, as others have suggested, there is no solution for it. Or, at
least no solution that you should bother with. The purpose of the
database is not to store the data in some particular view (order,
collation, grouping, etc.) that you might want to view it later in.
That is the reason the db provides methods to generate the views the
way you want them. The only imposition is that the db might sort them
internally by the PK, but that is also irrelevant -- the PK may not
always be numerical (as in the case of a GUID), hence, you could get
any old thing.

In short, don't bother trying to insert the data in a particular order,
because that is not what the db is designed for. Once you have the data
in the db, then use the power of the db to morph the data into whatever
views your heart desires.

>
>
> -Original Message-
> From: Steve O'Hara [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 30, 2005 5:28 PM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] Insert all rows from old table into new table
> but in
> sorted order
>
>
> I might be wrong, but if you don't specify a sort column, you will get
> the
> rows out in PRIMARY KEY order, irrespective of how you loaded the data.
> Therefore, you will need to do something a little more interesting
> with your
> loading statement to perhaps exclude the primary key and let the insert
> re-generate them.
>
> Just a thought.
>
> Steve
>
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:sqlite-users-return-6291-sohara=pivotal-
> [EMAIL PROTECTED]
> rg]On Behalf Of Paul Smith
> Sent: 30 June 2005 12:23
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Insert all rows from old table into new table but
> in sorted order
>
>
>
>> I can insert all rows of existing table into new table having same
>> columns
>> using query :
>>
>> Insert into NEWTABLE select * from OLDTABLE
>>
>> But I want all rows of NEWTABLE sorted by field No,
>>
>> So I used query
>>
>> Insert into NEWTABLE select * from OLDTABLE order by no desc
>>
>> But it is not giving me sorted output as new table?
>>
>> Can you tell me where I am wrong ???
>
> You can't do that.
>
> The 'Insert' may (I'm not sure..) insert the data into 'NEWTABLE' in
> the
> "right order" , but then, when you do an unordered query on
> 'NEWTABLE', the
> results are returned in an undefined order - not necessarily in the
> order
> they were inserted into the table
>
> You should do the sorting when you read 'NEWTABLE'
>
> So, instead of
>
> Insert into NEWTABLE select * from OLDTABLE order by no desc
> select * from NEWTABLE
>
>
> do
>
> Insert into NEWTABLE select * from OLDTABLE
> select * from NEWTABLE order by no desc
>
>
>
>
> PaulVPOP3 - Internet Email Server/Gateway
> [EMAIL PROTECTED]  http://www.pscs.co.uk/
>
>
>
>
>
>
>
>
--
Puneet Kishor

RE: [sqlite] Concurrency management

[Steve O'Hara]

There is no "queuing" of requests in SQLite - if a request (thread) is
blocked on a lock then it simply goes to sleep for a period of time and then
retries.  It doesn't know how many other threads are doing the same thing,
just that a thread somewhere has control of the database.
Therefore, there is no way of knowing the order in which your requests will
get satisfied.

Steve

-Original Message-
From: Ricaldone Simona-ASR008 [mailto:[EMAIL PROTECTED]
Sent: 23 March 2005 16:21
To: 'sqlite-users@sqlite.org'
Subject: [sqlite] Concurrency management


Hi all,
sorry but I'm new with SQLite.
I have tried to find an answer to the following question but unfortunatelly
I did't yet found it within the previous discussions.
In details my question is the following:

Scenario:
- platform: Linux ARM machine;
- application development language: C++;
- three different applications (A, B, C) try to write some data on an SQLite
database in sequence (almost contemporaneously);
- the sqlite_busy_timeout API has been invoked and has been set a timeout
equals to 5 seconds;
- if the write operations are quick (require less than 5 seconds to be
completed), at the beginning the application A will start to write data into
the database, while the applications B and C will wait;
- as soon as the application A will finish, the application B should start
and then at the end the application C should start to write on the database.

This is the expected behaviour.
But instead by doing some tests it seems to me that the requests order is
not always respected.

Is it possible to have more details about the requests queue management?
Which is the algorithmn adopted?

Please could you confirm me if the only way to be sure that the requests
order is always respected is to implement a queue and a scheduler right?

Thanks a lot in advance.
Best regards,
  Simona

RE: [sqlite] thoughts on a web-based front end to sqlite3 db?

[Steve O'Hara]

I'd like England to win the World Cup...
Perhaps we can do a swap.

-Original Message-
From: Dinsmore, Jeff [mailto:[EMAIL PROTECTED]
Sent: 08 March 2005 13:58
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] thoughts on a web-based front end to sqlite3 db?


I personally would prefer replies that don't contain vulgar/obscene
content.

Thanks.

Jeff Dinsmore
MIS - Interfaces
Ridgeview Medical Center
[EMAIL PROTECTED]
952.442.2191 x6592


-Original Message-
From: Richard Heyes [mailto:[EMAIL PROTECTED]
Sent: Monday, March 07, 2005 8:37 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] thoughts on a web-based front end to sqlite3 db?


Eli Burke wrote:
> I've been working on a project using sqlite3 since last fall. At the
> time, I knew that it would need a web-based front-end eventually. I
> have a very small bit of experience with PHP, and I assumed that PHP
> would support sqlite3 sooner or later. Well, it's later, and as far as

> I know, PHP is still using the 2.x branch.
>
> So, I was wondering if any of the more opinionated among you would
> care to suggest an interface language. It'll be on a Linux box,
> presumably running apache although I'm open to alternatives. The app
> itself uses sqlite3 for scheduling jobs and storing job data, so the
> web interface only needs to be able to insert some data and do
> visualization (pretty standard stuff I think).
>
> Ease of learning is a plus as I need to get something basic up and
> running fairly fast. I've heard good things about Python in that
respect.
> Does anyone have alternative suggestions, or if you agree that Python
Is
> Good, would you suggest using APSW, pysqlite, or something else?

Since noone has mentioned it yet, I'd suggest Brainfuck
(http://www.muppetlabs.com/~breadbox/bf/). Very easy to learn (only
eight instructions) so you should have something up and running pretty
quickly. Notably, it has some of the most elegant code structure I've
ever seen.

HTH.

--

Richard Heyes


Ridgeview Medical Center Confidentiality Notice: This email message,
including any attachments, is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.

RE: [sqlite] thoughts on a web-based front end to sqlite3 db?

[Steve O'Hara]

Here's my tuppence worth.

I come from an engineering background where you're taught that rigour is the
most important feature of any development.  I find that all the interpreted
environments tend not to be that great in this regard.  Also, I don't have
an axe to grind when it comes to the "anything but Microsoft" prejudice that
a lot of non-MS programmers seem to have.  So, I would say that you need to
decide what it is you're actually developing and then select a tool that is
going to achieve that result - here's some questions to ask yourself;

 a) Am I developing a web application or just providing some dynmic content

 b) Can I fix the deployment platform (Windows/Linux/Solaris)

 c) How much time have I got to develop this

 d) What level/quality of service do I need to provide

There are lots of other questions but these are good ones to try and resolve
straight off.

Most of the applications I am involved in writing are multi-developer,
corporate wide systems and as such, it's not practical to choose a toolset
that isn't supported by a good vendor and a large user base.  This tends to
narrow the choices down to commercial products like
.NET/Java/Delphi/C/C++/VB - by commerical I'm talking about the Development
Environments (IDE).

Over the years I've come to realise that programming is much the same in any
modern environment - same symantics, different syntax.  what really makes
the difference for me is the development environment, I'm at the age where I
can no longer bear the thought of using notepad/emacs/vi/vim as my
development editor for the sake of spending a few quid on a proper tool for
the job that has Intellisense, aut-formatting, syntax checking etc.

With that in mind, your choice is further narrowed and my current absolute
favourite is Java Servlets with JDBC using JetBrains IntelliJ.  Low cost,
professional, high performance, good CV fodder, beautiful IDE.
If your pockets are deeper and you're sticking with Windows then .NET and
ADO is quite frankly the best possible way to go.

Hey, you wanted an opinion

p.s. anyone using assembler in a web environment should be kept away from
sharp objects for their own safety!!




-Original Message-
From: Eli Burke [mailto:[EMAIL PROTECTED]
Sent: 07 March 2005 21:23
To: sqlite-users@sqlite.org
Subject: [sqlite] thoughts on a web-based front end to sqlite3 db?


I've been working on a project using sqlite3 since last fall. At the time,
I knew that it would need a web-based front-end eventually. I have a very
small bit of experience with PHP, and I assumed that PHP would support
sqlite3 sooner or later. Well, it's later, and as far as I know, PHP
is still using the 2.x branch.

So, I was wondering if any of the more opinionated among you would care
to suggest an interface language. It'll be on a Linux box, presumably
running apache although I'm open to alternatives. The app itself uses
sqlite3 for scheduling jobs and storing job data, so the web interface
only needs to be able to insert some data and do visualization
(pretty standard stuff I think).

Ease of learning is a plus as I need to get something basic up and
running fairly fast. I've heard good things about Python in that respect.
Does anyone have alternative suggestions, or if you agree that Python Is
Good, would you suggest using APSW, pysqlite, or something else?

Thanks,
Eli

RE: [sqlite] ticket 1147

[Steve O'Hara]

Speaking as a wrapper writer myself (VB Wrapper), I too don't need or make
any use of the column names but I can see where they might be being used by
other wrappers e.g. ODBC/ADO/OLEDB.

It's a convenient way for these guys to pick up field name bindings from
select statements i.e. it saves them having to parse the select statement to
determine the names of the returned columns.

e.g. for ADO

set objRecSet objConnection.execute("select * from table1,table2 where
table1.id=table2.id")
objRecSet.field("table1.id").value

If the full_column_name pragma is set, then SQLite gives back unambiguous
column names but if it isn't , then the wrapper writer would have to figure
out the location of the field by parsing the select statement and creating a
column name lookup for the returned columns.

I think that's the problem isn't it?

Steve



-Original Message-
From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
Sent: 28 February 2005 12:38
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] ticket 1147


On Mon, 2005-02-28 at 11:12 +0200, Cariotoglou Mike wrote:
> I understand that this "column names" issue is becoming a pain for the
> sqlite authors, but OTOH, it is very important for wrapper authors...
>

Why?  Why does anybody care what the column names in the result
are?  What are the column names used for other than to print a
header at the top of a table for human-readable output?

Remember that not all wrappers are done by third parties.
I ship the TCL wrapper with SQLite and for some reason I
have never felt the need to turn on long_names or short_names.
The default column names, whatever they might be, have
generally been acceptable.

So what is the difference?  What are all these other
wrappers doing that requires specific column names formats?
--
D. Richard Hipp <[EMAIL PROTECTED]>

RE: [sqlite] Making a SEQUENCE?

[Steve O'Hara]

Hi Dave,

Wrap your update and select inside a transaction - the transaction is atomic
in this regard and locks the table after the update and doesn't let it go
until the commit/rollback.  Others can read (they get the uncommitted values
of course) but can't update.  You will always get the latest uncommitted
values from selects within the transaction.

Steve

-Original Message-
From: Ulrik Petersen [mailto:[EMAIL PROTECTED]
Sent: 21 February 2005 10:21
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Making a SEQUENCE?


Hi Dave,

Brown, Dave wrote:

>I read that faq, but I dont see how that solves this yet. I understand how
>the insert will autoincrement, but I need to do "increment + return new
>value" in one atomic operation. If I just issue an insert, then try to use
>the new value from that table, I'm not guaranteed that someone else hasn't
>also incremented it further before I got to it.
>
>Do you see what I mean?
>
>
Yes. If you are using SQLite 2.8.X, then use:

int sqlite_last_insert_rowid(sqlite*);

http://www.sqlite.org/c_interface.html   Section 3.0


If you are using SQLite 3, then there is an analogous function:

http://www.sqlite.org/capi3ref.html#sqlite3_last_insert_rowid

/Ulrik

--
Ulrik Petersen, MA, B.Sc.
University of Aalborg, Denmark
Homepage: http://ulrikp.org

[sqlite] Locking in 3.0.6

[Steve O'Hara]

I'm wondering what logic I should employ to prevent mutual exclusion
occurring.

I'm using SQLite to record an audit trail from a web application - I count
the number of edits, searches and the maximum number of concurrent users.
Each user opens a connection to the database for the duration of their
session.

The audit logic is as follows;

   begin transaction
   select total from useractivity where event= .
   If lRows = 0 Then
   insert into useractivity ..
   Else
   update useractivity .
   End If
   commit transaction

What is happening is that the insertion/update in thread A locks the
database.  Before thread A gets the chance to commit the transaction, thread
B also attempts an update/insertion but fails because the database is
locked.  However, this causes thread A to also be locked out from committing
the change.  I don't have any recovery code in the logic so we're then in a
situation whereby the database is permanently locked for everyone, or until
all the sessions die and each thread closes it's handle.

This can't be right can it ?

Where should I do my busy checking and recovery logic to prevent this mutual
exclusion?

Steve

RE: [sqlite] Locking in 3.0.6

[Steve O'Hara]

Hi Richard,

I haven't had any response from anyone else so I thought I'd try you direct
Richard.

I'm wondering what logic I should employ to prevent mutual exclusion
occurring.

I'm using SQLite to record an audit trail from a web application - I count
the number of edits, searches and the maximum number of concurrent users.
Each user opens a connection to the database for the duration of their
session.

The audit logic is as follows;

   begin transaction
   select total from useractivity where event= .
   If lRows = 0 Then
   insert into useractivity(timestamp,datasource,event,total) values
..
   Else
   update useractivity set total=total+1 where datasource= .
   End If
   commit transaction

What is happening is that the insertion/update in thread A locks the
database.  Before thread A gets the chance to commit the transaction, thread
B also attempts an update/insertion.  This causes thread A to be locked out
from committing the change.  I don't have any recovery code in the logic so
we're then in a situation whereby the database is locked for everyone,
permanently or until all the sessions die and each thread closes it's
handle.

This can't be right can it ?

Where should I do my busy checking and recovery logic to prevent this mutual
exclusion?

Steve




-Original Message-
From: Steve O'Hara [mailto:[EMAIL PROTECTED]
Sent: 08 September 2004 01:42
To: [EMAIL PROTECTED]
Subject: [sqlite] Locking in 3.0.6



I'm having difficulty understanding the locking regime in SQLite 3.

I open the same database with 2 processes (sqlite3.exe for instance).
In process 1 I begin a transaction and insert a row.
In process 2 I also begin a transaction and insert a row - this fails on the
insert with an expected "database is locked" error
In process 1 I now do a commit, but this now also fails with "database is
locked" !!

Am I missing something here or is that a little odd ?

I assumed that the first thread to get a WRITE lock would be the controlling
thread and the database would be locked until that thread relinquished the
lock by calling commit or rollback.  How can it be that a writer that has a
change pending is blocked from committing that change by another thread that
hasn't actually attempted a change ?

Steve

RE: [sqlite] sqlite with Visual Basic

[Steve O'Hara]

The previous version included the SQLite code in the DLL.
This version loads the SQLite DLL at runtime and calls into it - that way
there is no built-in dependency on the SQLite version.

Steve

-Original Message-
From: Frederic Faure [mailto:[EMAIL PROTECTED]
Sent: 19 June 2004 11:52
To: [EMAIL PROTECTED]
Subject: RE: [sqlite] sqlite with Visual Basic


"Steve O'Hara" >> If you can think of improvements, let me know.

I noticed that the output DLL shrank yet again to 45KB :-) What did you do
to make it so small?

Fred.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] sqlite with Visual Basic

[Steve O'Hara]

I think you've missed the point...

The VB wrapper allows VB programmers (this includes ASP) to interface
directly to SQLite.
No half way houses, no strange connection of disparate apps, just
straight-forward Windows code.

As you say, if you're talking VB then you're obviously talking Windows, so
why propose a solution that isn't even proven on Windows?  JavaScript and
KDE, you're having a laugh?

Steve


-Original Message-
From: Hihn, Jason [mailto:[EMAIL PROTECTED]
Sent: 18 June 2004 18:52
To: [EMAIL PROTECTED]
Subject: RE: [sqlite] sqlite with Visual Basic


Again, I'm coming to this late...

While not VisualBasic, you could theoretically do it in JavaScript (just
as easy) using KJSEmbed.

KJSEmbed is a project that binds JavaScript to KDE. Now not Everyone is
KDE users, and since you're asking for VB, I'll assume you're on
windows. Well good news. There is a qt-only port that binds against Qt
(www.trolltech.com) (Qt includes a SQLite driver) so you can, with Qt,
use SQLite. Now this is still not 100%, because it only works under
Linux, and you need the CVS version ATM. BUT shortly (days - weeks
maximally) they will be releasing Win32-Qt-Only-KJSEmbed. It'll be a
couple DLLs and an EXE to run the script.

http://xmelegance.org/kjsembed/
http://xmelegance.org/kjsembed/examples/sql/sql.js

Currently, I am using KJSEmbed to create and run dialogs
platform-independently. There are glitches, but they usually get
everything fixed or added with 7 days (1 week)

-Original Message-
From: Jorge [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 4:41 PM
To: Jalil Vaidya; Jorge; [EMAIL PROTECTED]
Subject: Re: [sqlite] sqlite with Visual Basic

No, no...

there is not mentioned VBWrapper.zip


1) DLL for VB 6/5/4 like as ADO free!! by Javier Bermudez from
Argentina.
http://free.hostdepartment.com/j/javierbermudez/archivos/sqlite/index.ht
ml

isn't active

Visual Basic 6 http://www.ag-software.com/SQLite/default.asp
it's OK, but it isn't VBWrapper.zip

SQLHelper: http://groups.yahoo.com/group/sqlite/files/ (Works with VB5 &
VB6; Get both pssql.zip and psvbutls32.zip )
I am not yahoo group member

SQLitePlus COM DLL wrapper for SQLite (coded with C++/ATL).
http://www.sqliteplus.com ($$)
it isn't my favourite price!!!

TIA

Jorge



- Original Message -
From: "Jalil Vaidya" <[EMAIL PROTECTED]>
To: "Jorge" <[EMAIL PROTECTED]>; "Carlos Garces"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, June 17, 2004 5:50 PM
Subject: Re: [sqlite] sqlite with Visual Basic


Check out COM Wrappers / Visual Basic DLLs section in
the wiki:
http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers

HTH,

Jalil Vaidya

--- Jorge <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Are there any site whehe can I found the mentioned
> VBWrapper.zip?
>
> I have tried in http://f4.grp.yahoofs.com/..., but
> this URL isn't OK
>
> TIA
>
> Jorge Colaccini


=
01001010
0111
01101100
01101001
01101100




__
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] SQLite and ODBC

[Steve O'Hara]

Hi,

I find I have to agree with the opinion that says keep the ODBC driver
should be external to the SQLite source.

Why? Well, how many other database engines, client/server or otherwise, come
with an ODBC driver embedded with the engine?  The answer of course is none.
Plenty of vendors supply drivers for all kinds of technologies - JDBC, OLEDB
etc but I'm not aware of a single one that embeds the driver with their
engine.

Surely the beauty of a loosely coupled system is the flexibility afforded to
the developer to choose the interface that best suits their needs, whilst
still maintaining a small, robust and fast backend.
The SQLite download pages are testimony to the enthusiasm of developers for
creating SQLite interfaces for a wide variety of
languages/environments/platforms.

I've used the SQLite ODBC driver in an environment whereby we use SQLite to
simulate differing client/server backends and I've found, by and large, that
despite the authors caveat about it being experimental, it works really
well.  Certainly better than the OpenLink driver to Informix which it
simulates!

Also, I'd rather Richard et al were concentrating their minds on the things
I CAN'T do, like improving the engine, rather than wasting their time
re-inventing the wheel on things I CAN do...

Steve


-Original Message-
From: Raymond Irving [mailto:[EMAIL PROTECTED]
Sent: 17 May 2004 21:08
To: [EMAIL PROTECTED]
Subject: RE: [sqlite] SQLite and ODBC



Hi,

I've download the version at http://www.ch-werner.de/sqliteodbc/ and it
works just fine. I was only making a suggestion that such a cool database
should come bundled with an ODBC driver (meaning it's part of the
development).

SQLite is very cool but it does not make any sense if it can't be (easily)
integrated with existing components. Rather than having the ODBC driver
separate I would suggest that it be a part of the teams plan for future
versions. Darren said that this would add more load the the developers but I
don't think it should really.

Making SQLite more connectable is something that the team should also
consider. Not everyone uses C or C++ and not all components have an
interface to bind an array. We just have to look at what tools we have
available and see how best we can make them integrate-able.

__
Raymond Irving



"Griggs, Donald" <[EMAIL PROTECTED]> wrote:
Regarding: "I was more think of ways to get an SQLite Database connected to
every day database objects and controls."

A good point!

This may be a naive comment of mine, but if you just forgot about the
vanilla sqlite download page, and instead considered page:
http://www.ch-werner.de/sqliteodbc/
to be THE release point for sqlite-cum-ODBC, would that not give you what
you need?


[writing for myself, and not on behalf of my company]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] sqlite with Visual Basic

[Steve O'Hara]

Hi Murray,

Installshield has a method for creating ODBC configurations as part of the
setup.
If I remember, I think that there is an MS API for interacting with the ODBC
setup - if all else fails, do it yourself by writing to the appropriate
places in the registry.

Steve

-Original Message-
From: Murray Moffatt [mailto:[EMAIL PROTECTED]
Sent: 17 May 2004 05:14
To: [EMAIL PROTECTED]
Subject: RE: [sqlite] sqlite with Visual Basic


I'm interested in using SQLite from within a Visual Basic 6 app that I'm
writing. I need reporting features and so was looking at using Crystal
Reports.

I'm guessing that it would be easiest to use SQLite ODBC for accessing the
SQLite database, as the VB tools and Crystal Reports support ODBC.

When I downloaded SQLite ODBC from http://www.ch-werner.de/sqliteodbc/ and
looked at the readme file I was a bit concerned when I read that this was
still "experimental". Obviously if I want to distribute my app to others I
want something that isn't going to bomb out every so often! If anyone else
is using SQLite ODBC in an app I'd like to hear how stable it is?

Also the readme file says that it has to be installed and databases set up
by using the ODBC Control Panel applet. Obviously I don't want to have to
tell people that they have to set all this up themselves by hand after they
install my app, so is there any way I can programmatically set up the ODBC
connection? Either via my installation program or within the main app
itself?


At 20:32 16/05/2004 +0200, you wrote:


  Personally, I use my own wrapper (attached) with Greg Obleshchuk's
  AGS_SQLite.dll. It is very simple to use (it will generate the SQL code
for
  you):

  Dim db as ADOSQLite
  Set db = new ADOSQLite

  db.Connect "database.db"
  db.Table = "mytable"
  db.Action = ActionSelect
  db.Sort = "id"
  db.Where = "id < 100"
  db.Exec
  If Not db.Err Then
  do while not db.EOF
  debug.print db.field("id")
  db.MoveNext
  Loop
  End if

  Of course this runs "in-memory" so if this is a concern for you, then try
to
  narrow down your selects.

  Cheers!
  Chris

  > -Original Message-
  > From: Raymond Irving [mailto:[EMAIL PROTECTED]
  > Sent: 14 May 2004 17:50
  > To: [EMAIL PROTECTED]
  > Subject: Re: [sqlite] sqlite with Visual Basic
  >
  >
  > I use SQLite ODBC with ADO to access databases from VB. It
  > works like a charm.
  >
  > http://www.ch-werner.de/sqliteodbc/
  >
  > __
  > Raymond Irving
  >
  >
  > Jérôme_VERITE <[EMAIL PROTECTED]> wrote:
  > I use this wrapper and to simplify again the code, I created
  > littles classes which are very simple and look like the DAO
  > classes. It permits to transform Simply a VB application
  > using DAO to SQLITE
  >
  > Jérôme
  >
  > -Message d'origine-
  > De : Steve O'Hara [mailto:[EMAIL PROTECTED]
  > Envoyé : vendredi 14 mai 2004 10:35
  > À : Jalil Vaidya; Carlos Garces; [EMAIL PROTECTED]
  > Objet : RE: [sqlite] sqlite with Visual Basic
  >
  >
  > Here's the SQLite wrapper for VB from the Yahoo groups
  >
  > Steve
  >
  > -Original Message-
  > From: Jalil Vaidya [mailto:[EMAIL PROTECTED]
  > Sent: 14 May 2004 02:13
  > To: Carlos Garces; [EMAIL PROTECTED]
  > Subject: Re: [sqlite] sqlite with Visual Basic
  >
  >
  > There is a VBWrapper.zip in the old SQLite yahoo
  > group's file section. The archive contains wrapper
  > over the SQLite API so that it can be used from VB.
  > The API declarations for VB are also in the archieve.
  > Get it from here:
  >
  > http://f4.grp.yahoofs.com/v1/EBqkQKgMWwt8clzVakFnZ6GAGVancQ9q-
  > 4gKNXEFX9QQmKI
  > vHaVaTJ9rp1fz-XHaFxRIq46etnp1v_WDUrQPABeSNps/VB%20Wrapper
  >
  > If you cannot download from the link above then you
  > will have to join the group to get it.
  >
  > HTH,
  >
  > Jalil Vaidya
  >
  > Disclaimer: I have never used this wrapper myself.
  >
  > --- Carlos Garces wrote:
  > > Hi!
  > > I can use SQLLite with Visual Basic without using
  > > other external DLL
  > > Any sample of using sqlite.dll API?
  > >
  > > Thanks
  > > Carlos Garcis
  >
  >
  > =
  > 01001010
  > 0111
  > 01101100
  > 01101001
  > 01101100
  >
  >
  >
  >
  > __
  > Do you Yahoo!?
  > Yahoo! Movies - Buy advance tickets for 'Shrek 2'
  > http://movies.yahoo.com/showtimes/movie?mid=1808405861
  >
  > -
  > To unsubscribe, e-mail: [EMAIL PROTECTED]
  > For additional commands, e-mail: [EMAIL PROTECTED]
  >
  >
  >
  > > ATTACHMENT part 2 application/x-zip-compresse

RE: [sqlite] vers 3.0 concurrency issues

[Steve O'Hara]

Hold up there trigger, I didn't mean for everyone to launch into a blow by
blow comparison of features between various RDBMS.
My point was that in terms of concurrency, how does SQLite compare with
other non-supervised databases technologies like JET (Access), Paradox etc.
That way, any criticism of SQLite's shortcomings in this area can be fairly
judged.

On a more general point, I too am a SQLite zealot and have a great deal of
admiration for Richard's work.  However, I'm not blinkered into thinking
that there aren't other technologies that may offer other features.

It's often horses for courses, one solution never fits all in my experience.
JET is probably the most prevalent relational database technology in the
world today, thanks to it being used in projects ranging from school
homework to foreign exchange management so it's a little glib to question
whether the developers at MS "...have a clue".  I'm not saying it's the best
or fastest but it must have something going for it...

Steve



-Original Message-
From: Puneet Kishor [mailto:[EMAIL PROTECTED]
Sent: 06 May 2004 18:59
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [sqlite] vers 3.0 concurrency issues



On May 6, 2004, at 12:24 PM, Steve O'Hara wrote:

> I've been watching the discussion about concurrency with interest.  I
> find
> I'm impressed by everybody's arguments.
>
> I'd too would like to keep SQLite small and fast but equally, I'd like
> to
> have better concurrency.  Even if this is just a safeguard for the
> future.
>
> However, I'm wondering why we're comparing SQLite with kernel based
> RDBMS
> like Oracle etc, and not with it's more closely related cousins such as
> Access ?
>
> In this regard, how does SQLite compare with
> Access/FoxPro/Paradox/dBase ?
>

I can comment on it from a user/appdeveloper's perspective -- a very
subjective, my perpective.

Things that SQLite can do that Access or FilemakerPro (two I have
worked with) cannot do -- SQLite is fanstastically fast, supports
transactions, and runs identically and equally happily on my Win box at
work and iBook at home... no data conversion, no hassles.

Things that SQLite sucks at (if you pardon the expression) compared to
Access and FMPro -- ALTERing tables is a royal pain in the behind. I am
constantly in need of ALTERing the tables and queries (views) as I am
developing the application, and to do this is just... well, not nice.

So... the real answer to "how does SQLite compare with ?" is "it depends."


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] vers 3.0 concurrency issues

[Steve O'Hara]

I've been watching the discussion about concurrency with interest.  I find
I'm impressed by everybody's arguments.

I'd too would like to keep SQLite small and fast but equally, I'd like to
have better concurrency.  Even if this is just a safeguard for the future.

However, I'm wondering why we're comparing SQLite with kernel based RDBMS
like Oracle etc, and not with it's more closely related cousins such as
Access ?

In this regard, how does SQLite compare with Access/FoxPro/Paradox/dBase ?

Steve



-Original Message-
From: Andrew Piskorski [mailto:[EMAIL PROTECTED]
Sent: 06 May 2004 17:53
To: [EMAIL PROTECTED]
Subject: Re: [sqlite] vers 3.0 concurrency issues


On Thu, May 06, 2004 at 09:54:24AM -0400, D. Richard Hipp wrote:

> Concurrency is not nearly as much an issue in reality
> as it is in many peoples imagination.  Concurrency
> probably is not an issue for a website. If concurrency
> really is an issue, you need a client/server database.

While that might be true [I take no position on whether it is or not],
to some real extent it may also be irrelevent.  Here's my theory:

People often don't know ahead of time, and aren't able to reasonably
predict, just how much concurrency they will need.  Also, their
concurrency needs may change over time, again in ways that are hard
for them to predict.

Therefore, picking a tool which they KNOW has serious concurrency
limitations introduces a significant risk, the risk that they may have
to drastically overhaul their underlying tools and architecture at
some unknown point in the future, due to hitting concurrency problems
and thus suddenly discovering that they're now using the wrong tool
for the job.

Since SQLite's concurrency support is very limited, potential users
are forced to pre-maturely optimize:  Either believe you will need high
concurrency, and go with PostgreSQL or Oracle, or believe you will
need no or low concurrency, and go with SQLite.  Premature
optimization is a bad thing.

There is a missing middle ground there: A medium-concurrency SQLite.

If a future version of SQLite - let's call it "SQLiteMC" - were able
to significantly increase concurrency, while at the same time
preserving all or most of SQLite's historical advantages (simplicity,
etc.), this would significantly expand the problem domain to which
SQLite is applicable.  That, in turn, would reduce the "wrong tool"
risk of using SQLite, and both of those effects would tend to make
SQLiteMC both more useful and more widely used than SQLite is now.

That's my little mental model anyway.  To me the direction of those
effects seems just about certain, but what I don't know - and can't
know, much less quantify - is the size of those effects - they could
be anywhere from zero to large.  And of course, that's assuming that
SQLiteMC succeeds in its technical goals.

And would SQLiteMC succeed in its technical goals?  How hard would it
be, and are there sufficient programmer resources available to make it
happen?  That I don't really know either, but together, Dr. Hipp plus
a few other experts on this list could probably come up with a
reasonably good idea...

--
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] A proposal for SQLite version 3.0

[Steve O'Hara]

I agree with Greg, the most irksome feature of SQLite is the case
sensititvity - it's one of the few things MS got right with SQLserver.  I
know this is more mainstream/standard SQL behaviour but it's outdated in
modern SQL applications that nearly always do some kind of linguistic
searching.
In fact, I'd go one step further and advocate making SQLite case-insensitive
as a rule.
I'm waiting for the flames...

Steve


-Original Message-
From: Greg Obleshchuk [mailto:[EMAIL PROTECTED]
Sent: 11 April 2004 23:02
To: D. Richard Hipp; [EMAIL PROTECTED]
Subject: Re: [sqlite] A proposal for SQLite version 3.0


Hello,
I just read the proposed changes and they seem fine.  A couple of thing.

The data types I think are great but can we have a large and small integer?
I noticed some people (embedded systems people) complain about this.  I
quite happy with the large type but as integers will now be stored as the
native type that will double the storage requirement for numbers (64-bit
integer taking 8bytes where 32 take 4bytes)  So may be something like
if the value is a number then check to see if it fits in a 32bit integer if
it does use that otherwise use a 64 bit.  If this is too much trouble in
code then maybe a compile directive to use a certain size integer.

When using a INTEGER PRIMARY KEY perhaps we could use

INTEGER SMALL PRIMARY KEY
and
INTEGER LARGE PRIMARY KEY

Support for user definable collating.  I'm assuming that this will give us
the ability to turn SQLite into a non case sensitive system by defining our
own collation which is not case sensitive?  Which is great and you state
that there will be two predefined collations
COLLATE TEXT and COLLATE NUMERIC.  Can I suggest that you create a third
pre-defined collation (to make it easy on us that want it) can you create a
COLLATE TEXT_CI .  Which would be a case in-sensitive collation.  Then the
people that really want this can use it off the bad, as it were.  I'm sure
it will be a lot easier for you to create it that for someone else.

API and preferred way of executing queries
I'm assuming there will still be the wrapper to execute a SQL in one line .
You state that there may or may not be the call-back function wrapper.  I
would be an advocate for keeping it.  This way of handling returned data is
most useful.  Sometimes when returning thousands or more rows of data you
want to cancel the statement without a call-back function you must wait
until the statement is finished and then discard the result.  Having a
call-back allows you (or the user) to terminate the statement.

Apart from that great changes , more complete but things change and grow
(which is good).  If I had to decide which is my most wanted feature from
the stuff above I would say COLLATE TEXT_CI as this would enable me to use =
instead of LIKE in my lookups (I really don't like case sensitive data in
the real world)

kind regards
Greg O

  - Original Message -
  From: D. Richard Hipp
  To: [EMAIL PROTECTED]
  Sent: Wednesday, April 07, 2004 11:22 PM
  Subject: [sqlite] A proposal for SQLite version 3.0


  A design proposal for SQLite version 3.0 can be found at:

   http://www.sqlite.org/prop2.html

  Feedback from the user community is strongly encouraged.
  An executive summary of the proposed changes follows:

  *  Support for UTF-16
  *  Better BLOB support
  *  User-defined collating sequences (for better
 internationalization support)
  *  Smaller and faster than 2.8.13.

  The plan is to continue to support the 2.8.X series
  indefinately and in parallel to the 3.X series.  But
  the only changes to 2.8.X going forward will be bug
  fixes.  New features will go into 3.X.  Beta releases
  of version 3.X are expected within a few months.

  I do not have much experience with UTF-16 and am
  expecially interested in feedback on that area of
  the design.
  --
  D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565


  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] Matching telephone strings

[Steve O'Hara]

What about this;

SELECT * FROM stdcodes WHERE '0018764582' LIKE areacode || '%' order by
areacode desc limit 1;

Steve

-Original Message-
From: Lloyd thomas [mailto:[EMAIL PROTECTED]
Sent: 11 April 2004 15:00
To: [EMAIL PROTECTED]
Subject: Re: [sqlite] Matching telephone strings


>I think I have sussed it.<
Well not quite!!
 If I extend the 'select' parameter to include other columns, there are
instances where the results in those columns may not be related to what is
in the left columns (as I would expect) and if you group the results, you
end up with more than one result(albeit the best match seems to be first).
The following query seems to sort it out, but is it correct?

sql---
select MAX(areacode) as areacode, band, destination from stdcodes where
'001212' like areacode || '%' group by areacode limit 0,1;
-

> I think I have sussed it. If you can see something wrong with the follwing
> let me know.
>
> code-
> SELECT MAX(areacode) AS areacode FROM stdcodes WHERE '0018764582' LIKE
> areacode || '%';
> ---
>
>
> > Thanks Kurt,
> > The GUI I was using to run the query seems to be
using
> > an old version of the SQLite DLL. I haved tried another one and the
query
> > has got me closer to what I want.
> > The problem I now have is that I am getting too many results.
> > ie.
> > SELECT areacode FROM stdcodes WHERE '0018764582' LIKE areacode || '%';
> >
> > results:
> > 001 USA
> > 001876 Jamaica
> >
> > As you can see the second result is the correct one, is there a way I
can
> > narrow down the result to the nearest fit?
> >
> >
> > > > I tried the follwing with no results:
> > > >
> > > > select areacode from stdcodes where '01865323260' like areacode ||
'%'
> > >
> > > Don't know what to tell you.  Here's an actual query:
> > >
> > >   sqlite> select id from entities where 'tmkxyz' like id || '%';
> > >   id
> > >   --
> > >   tmk
> > >
> > > Looks analogous to what you're trying to do.
> > >
> > > What version of SQLite are you using?
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] Clustered indicies Was: [sqlite] A proposal for SQLite version 3.0

[Steve O'Hara]

Ben,

I think you're asking for is a mechanism to define the nature of the primary
key.
e.g. If you could define the primary key as some kind of function or to use
a specific integer field, then the table will be naturally ordered by that
field.

I don't know about other SQL engines, but our baby (BASIS) allows you to
create your primary key like this - this gives us tremendous performance
improvements for some apps.  For instances, we have some clients who store
newspaper articles from various publications in a table.  The natural way in
which users want to see these articles is sorted by the published date,
latest first - that's fine, but these tables contain 40 million articles and
their queries can produce pretty large sets.  We create a primary key based
on the published date which means we don't need to sort their queries.

Just a thought

Steve


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 08 April 2004 04:05
To: [EMAIL PROTECTED]
Subject: [sqlite] Clustered indicies Was: [sqlite] A proposal for SQLite
version 3.0


Jeff,





Jeff Pleimling <[EMAIL PROTECTED]>
08/04/2004 12:42 PM


To: [EMAIL PROTECTED]
cc:
Subject:Re: [sqlite] A proposal for SQLite version 3.0


At 12:08 PM 4/8/2004 +1000, [EMAIL PROTECTED] wrote:
> I believe you're thinking of a 'clustered index'. This puts the data
> into the order of the index. There can be, of course, only one clustered
> index per table.
> Since at least some of the data in the table is moved around on every
insert,
> regular indexs need to take this into account (usually by indirection,
rather
> then modifying all of the indexes with each insert).

Ahh, I didn't think of that. I don't have any other indices on my table,
so this wouldn't be a problem for me... but I can see now how it would
harm the general case. I guess the simplest implementation would have a
proabition on having -any- other indicies on the table.

> >If a table could be ordered according to an index, rather than having
an
> >external index, I think it would significantly improve the time and
space
> >performance of my databases. I don't know whether my experience would
be
> >shared by other users. It it were something that could go into 3.0 it
> >would at least do me some good.
> Clustered indexes can really slow the performance for OLTP (On-Line
> Transaction Processing) and other systems where data is added/deleted in
a
> mixed fashion. Every time a record is inserted, data is possibly moved
on
> the disk (with page splits causing even more slowdowns).

Yes, that's what's happening already in the index whenever I do an insert.
My thinking was that maintaining an index-ordered table would be less work
overall than maintaining a table with an ordered index. I could be wrong
on that, but I'm not sure I see the flaw in my logic.

> If your system is entirely historic data, that would be great - but if
your
> system is inserting meter readings in (near) real-time, you'd probably
> get a big performance hit.

It's certainly real-time, with the occasional query.

> There are many pros and cons. A google search turns up articles (usually
for
> MS SQL Server) on both side - some people saying 'always' and some
'never'.

I can certainly see how the usefulness of this feature could be limited.

I guess the problem is primarily related to how the rowid is chosen. If I
could choose a rowid that would put the table in the correct order, and
renumber as required I might make some ground. I could order by ROWID,
then... although there may have to be some kind of code tweakage to allow
the where clauses to operate correctly.

Hmm... maybe something like this:
BEGIN TRANSACTION;
SELECT * FROM mytable WHERE 
-- if the insertion point is after current data:
INSERT INTO mytable VALUES (MAX(ROWID) + 10, )
-- else if insertion point is between two values
INSERT INTO mytable VALUES (( + )/2, )
-- else rearrange contiguous values
UPDATE mytable SET ROWID = ROWID+1 WHERE ROWID >=  AND
ROWID < 
INSERT INTO mytable VALUES (, )
END TRANSACTION;

Perhaps the changes to sqlite could be as minimal as providing a facility
to say:
"I promise to keep these rows in an order consistent with this index"
so sqlite will use the index in queries.

Benjamin.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] A proposal for SQLite version 3.0

[Steve O'Hara]

Wouldn't this be due to SQLite storing everything as strings?
If your database is predominantly numbers then I imagine the differences
between Access and SQLite could be huge.

Steve

-Original Message-
From: Roy Black [mailto:[EMAIL PROTECTED]
Sent: 08 April 2004 04:38
To: [EMAIL PROTECTED]
Subject: Fw: [sqlite] A proposal for SQLite version 3.0


I have no clue how Jakub Adamek gets 3x bigger files than MS Access. I
always get 2x less.

- Original Message -
From: "D. Richard Hipp" <[EMAIL PROTECTED]>
To: "Jakub Adamek" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, April 07, 2004 9:10 AM
Subject: Re: [sqlite] A proposal for SQLite version 3.0


Jakub Adamek wrote:
 > My experience is that SQLite makes roughly about 3x bigger files than MS
 > Access. How would this change in 3.0?
 >

SQLite is very storage efficient in the common case.  In a typical
table, SQLite will use about 4 or 5 bytes of disk space for every 3 bytes
of actual data stored.  Put another way, about 60% to 75% of an
SQLite database file is the actual data being stored and the other
40% to 25% is overhead.

If you have an example where the overhead is significantly larger than
this, I'd be interested in seeing it.

The new version 3.0 file format is anticipated to reduce overhead by
about 5%.  YMMV, of course.

--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] Full text search implementation

[Steve O'Hara]

> -Original Message-
> From: Bertrand Mansion [mailto:[EMAIL PROTECTED]
> Sent: 16 January 2004 19:18
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [sqlite] Full text search implementation
>
>
> <[EMAIL PROTECTED]> wrote :
>
> >
> >
> >> -Original Message-
> >> From: David Morel [mailto:[EMAIL PROTECTED]
> >> Sent: 16 January 2004 17:32
> >> To: Brad Campbell
> >> Cc: George Ionescu; [EMAIL PROTECTED]
> >> Subject: Re: [sqlite] Full text search implementation
> >>
> >>
> >>> My regex patch should do that
> >>>
> >>> SELECT * FROM Categories WHERE CategoryDescription RLIKE
> >> 'Beverages" and CategoryDescription NOT
> >>> RLIKE 'Whiskey';
> >>>
> >>
> >> In such a simple string matching I suspect a regex search is totally
> >> overkill... that's ok for a db containing 1000 rows, but try it on
> >> 700,000 rows (390Mb) like the one i have here ;-)
> >>
> > I don't think that your LIKE version will perform much better - SQLite
> > doesn't use indexes when doing LIKE comparisons.
> >
> >>> -
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >> --
> >> ***
> >> [EMAIL PROTECTED]
> >> OpenPGP public key: http://www.amakuru.net/dmorel.asc
> >> 28192ef126bc871757cb7d97f4a44536
> >>
> >>
> >>
> >
> > Using LIKE as a means of doing a full text search is virtually
> useless in
> > the real world of text retrieval.  The query take no account of context,
> > which is essential when dealing with intelligent text queries.
> > A full-on full text engine (BASIS, BRS etc) has to maintain a set of
> > meta-data for each text column that can be searched i.e.
> >
> > When data is added to a text column, the text must be parsed to
> split it up
> > into searchable words using a break character list.
> > These words must then be reduced to their searchable stem
> (pluralisation,
> > inflexions, Porter stemming etc) and insignificant words ('a',
> 'and', 'the'
> > etc (stop words)) removed.
> > The words are then added to the column index - the posting in the index
> > contains the row ID, the start character position of the word and the
> > original length of the word.  It may also contain grammatical
> context info
> > such as the sentence/paragraph number.
> > At this point, some systems may also add into the index other
> variants of
> > the words (common mispellings, morphs etc) to improve recall.
> >
> > Now, when you do a search on that column, the system has to
> parse your query
> > terms, stem them and weed out stop words in the same way as
> when data was
> > added.  It then looks up the words in the column index and collates the
> > proximity of the words.
> > There's not normally much point in searching for 'SQLite' and
> 'document' if
> > you can't tell the system to find them with the same sentence,
> paragraph, or
> > adjacent.
> >
> > As you can see, a proper full text search engine is
> considerably more work
> > than it first looks.  Add onto this all the complexities of
> applying this to
> > different languages and you have a pretty major coding effort
> on your hands.
> >
> > I have a working prototype of such a beast using SQLite that I'd be
> > interested in sharing the devlopment of, if anyone is interested?
>
> I agree. You just forgot about the scoring algorithm, a full text query
> should also be able to return a score.
>
> IMO, search engines (with tokenizer, indexer, stemmer, stopwords,
> substrings, fuzzy, binary converter...) offer a good choice in terms of
> features when it comes to full text search. It seems that Mnogosearch
> (http://www.mnogosearch.org) has included sqlite as their default db for
> their search engine software. So this might be a good companion to sqlite.
>
> The best solution would be IMO to have all this optionally integrated into
> the database engine. That's what Oracle does with Context and last time I
> have used it, it was working very well (it was with Oracle 9i). But that
> might also make the engine too heavy.
>
> Mysql offers fulltext but it is only available AFAIK on the MyISAM table
> format. So you can't have foreign key constraints (available on InnoDB
> format) and full text at the same time.
>
> Bertrand Mansion
> Mamasam
>
>

Yes you're right, all full text engines have a ranking mechanism.  Some also
have term weighting which is very useful especially if it is dynamic.

Interestingly, when I first looked at Context some years ago, it was
apparent that the full text search functions are not actually part of the
core database engine.
The Context portion is actually a layer that surrounds the Oracle kernel and
uses standard SQL services to achieve the full text capability i.e. for
every column that is free text searchable, a surrogate table is created that
contains the terms, positions etc of the terms from that column.
The Context layer then runs standard SQL 

RE: [sqlite] Full text search implementation

[Steve O'Hara]

> -Original Message-
> From: David Morel [mailto:[EMAIL PROTECTED]
> Sent: 16 January 2004 17:32
> To: Brad Campbell
> Cc: George Ionescu; [EMAIL PROTECTED]
> Subject: Re: [sqlite] Full text search implementation
>
>
> > My regex patch should do that
> >
> > SELECT * FROM Categories WHERE CategoryDescription RLIKE
> 'Beverages" and CategoryDescription NOT
> > RLIKE 'Whiskey';
> >
>
> In such a simple string matching I suspect a regex search is totally
> overkill... that's ok for a db containing 1000 rows, but try it on
> 700,000 rows (390Mb) like the one i have here ;-)
>
I don't think that your LIKE version will perform much better - SQLite
doesn't use indexes when doing LIKE comparisons.

> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> --
> ***
> [EMAIL PROTECTED]
> OpenPGP public key: http://www.amakuru.net/dmorel.asc
> 28192ef126bc871757cb7d97f4a44536
>
>
>

Using LIKE as a means of doing a full text search is virtually useless in
the real world of text retrieval.  The query take no account of context,
which is essential when dealing with intelligent text queries.
A full-on full text engine (BASIS, BRS etc) has to maintain a set of
meta-data for each text column that can be searched i.e.

When data is added to a text column, the text must be parsed to split it up
into searchable words using a break character list.
These words must then be reduced to their searchable stem (pluralisation,
inflexions, Porter stemming etc) and insignificant words ('a', 'and', 'the'
etc (stop words)) removed.
The words are then added to the column index - the posting in the index
contains the row ID, the start character position of the word and the
original length of the word.  It may also contain grammatical context info
such as the sentence/paragraph number.
At this point, some systems may also add into the index other variants of
the words (common mispellings, morphs etc) to improve recall.

Now, when you do a search on that column, the system has to parse your query
terms, stem them and weed out stop words in the same way as when data was
added.  It then looks up the words in the column index and collates the
proximity of the words.
There's not normally much point in searching for 'SQLite' and 'document' if
you can't tell the system to find them with the same sentence, paragraph, or
adjacent.

As you can see, a proper full text search engine is considerably more work
than it first looks.  Add onto this all the complexities of applying this to
different languages and you have a pretty major coding effort on your hands.

I have a working prototype of such a beast using SQLite that I'd be
interested in sharing the devlopment of, if anyone is interested?

Steve




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] Subject: Re: [sqlite] Let us make SQLite more powerful

[Steve O'Hara]

> -Original Message-
> From: Mrs. Brisby [mailto:[EMAIL PROTECTED]
> Sent: 29 December 2003 23:41
> To: Yogesh Vachhani
> Cc: [EMAIL PROTECTED]
> Subject: Re: [sqlite] Subject: Re: [sqlite] Let us make SQLite more
> powerful
>
>
> On Sat, 2003-12-27 at 07:16, Yogesh Vachhani wrote:
> > > Why exactly do you think the JOIN operator is the wrong tool for
> > > this?
> >
> > I feel JOIN operations are taxing on the Process as well as on RAM
> > and HDD (in form of temporary files)
>
> All right then. SQLite doesn't produce temporary files for JOIN, and
> your query _can_ be expressed relationally as a JOIN, so it should never
> be any faster than a JOIN operation- except due to parsing. Can you
> verify that parsing is taking "too long" here?
>

My understanding is that logically, by their very nature, joins are always
likely to be slower than single table queries - I thought that this was a
given downside to normalisation or am I incorrect?  Maybe the downside is
not pronounced in SQLite but I'm sure that you see it in other RDBMS (if you
crank up the results set volume enough).

>
> > > If you think this is easier to read, then consider creating VIEWs
> > > to
> > > store intermediate queries.
> >
> > I have never considered this as I am not a power user of SQLite.
> > Sorry...!
>
> VIEWs are quite normal in other SQL providers. That said, you may want
> to become more familiar with SQL before you start suggesting extensions
> to it- at the very least, be aware that syntactical additions may very
> well be fine, but you will face criticism if your reasoning is flawed.
>

In SQLite, VIEWs are simply an expedient for expressing your query - there
is no performance upside to using them opposed to a fully specified SQL
command.

>
> > > > So one can see that one would not lose anything by using SQLite's
> > > > extended storage model (if implemented). Even though the
> > > LineItems
> > > > information is embedded into the Invoices table, one can still
> > > write
> > > > a simple query to access it as if it were in an independent
> > > table.
> > >
> > > Backwards compatibility gets lost.
> > > API changes so programs need to be altered.
> > I did say at the start that we should extend the existing
> > functionality so that who are comfortable with the existing on will
> > keep on using this one and other can try out the other one!
> >
> > This not lead to lost in BACKWARD compatibility?!
>
> If you have a table which has a value that can return multiple values
> you MUST alter the API of the callback function or of the fetch
> function. Otherwise how is older code supposed to deal with a table
> having multiple values in an attribute?
>

Why?
Most systems will return you the whole column value with delimiter
character(s) separating the sub-fields.
I think the alterations to the API will not be in the callback at all, but
WILL be in the query processor and index engine.
We are talking about changing the search engine to delineate certain field
values when querying.  It's easier for the indexer, which simply creates
multiple postings for the same record but with different terms (each
sub-field).

>
> > > That's an idea
> > > anyway, it can already be done with SQLite by supplying your own
> > > function. Additionally, you could add lists like this yourself
> > > (pick a terminator, and make a function that indexes)
> >
> > By the way does  anyone know whether SQLite supports User Defined
> > Functions? If such a thing is possible then all such functionality
> > can be implementd out side SQLite in a separate DLL. What do u all
> > think?
>
> Yes, SQLite supports "user-defined" functions. The Wiki has a great deal
> of documentation about this...
>
> > > Generally speaking, I think that trying to store an unknown number
> > > of distinct values in one record column is a bad idea, and it
> > > violates level 1 normalization.  You really should use a separate
> > > table for the phone numbers and/or addresses, one record per
> > > instance.
> >
> > It does not violate some of the normalization rules but then how many
> > follow this pracitcally. In fact I have noticed that in practicaly
> > implementations many times a developer has to avoid normalization
> > rules to implement some pecular requirements of their customers
>
> I do not think you know what you are talking about. "level 1
> normalization" comes from graph theory and describes a manner in which
> every graph can be translated into another graph as utilizing no nested
> functions - which are called "level 1 normal forms".
>
> I don't think the responder quite spoke correctly either. The structure
> you desire _can_ be folded down (normalized) into the view normal people
> have of SQL: You aren't suggesting that anything be made available that
> isn't presently available- but you want to write these systems without
> learning SQL, or because you believe giving syntactical hints will make
> queries run faster.
>
> I do think that this 

RE: [sqlite] Sqlite & COM/EXE server

[Steve O'Hara]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 27 December 2003 16:19
To: [EMAIL PROTECTED]
Subject: RE: [sqlite] Sqlite & COM/EXE server



> Hi,
>
> I've used SQLite in a variety of COM situations without problems.
>
> What is your application environment (asp/client-server/desktop)?
> Is your COM EXE written in VB?
> Are you using a custom DLL to interface to the SQLite DLL?
> How is your COM EXE threaded (free/apartment/single)?
>
> I've used the SQLite VB DLL from Pivotal (download from the Yahoo files
> section) without encountering any of these problems.
> The only reason why you would need to delve into DCOMCNFG is because you
are
> either running the EXE from ASP or from a Service.  In which case, you
would
> need to make sure that the launching user of your EXE has correct
> permissions to launch/access your objects.  Equally, the EXE will need
> permissions to the directories where SQLite writes its temp files.
>

The EXE must have a desktop when it wants to create Windows, in MS WIndows
a lot of code is creating invisible Windows, only Interactive Users are
allowed to do
so, there about is the problem with out of process COM-objects and services,
I
forget the exact how and why, but maybe this helps to find the answer

Bert Verhees

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


It is very rare that you would ever want to create windows from within a COM
EXE - the whole point of such a beast is to provide object services to your
front/back end, not normally to provide user interfaces (that's where OCX's
come in).
Also, your assertion that you cannot do this is incorrect - if you create a
window within a COM EXE that isn't set to interact with the Desktop, then no
user can see it, that's all.

The permissions issue is a commen problem for ASP applications that
instantiate COM EXE - these EXEs run with the default DCOMCNFG rights unless
otherwise configured, which are pretty onerous.

Steve





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] How to compile a standalone wrapper?!

[Steve O'Hara]

Easiest way is to include the sqlite.lib file in your library path.

Steve


-Original Message-
From: Sören Krings [mailto:[EMAIL PROTECTED]
Sent: 17 December 2003 11:29
To: [EMAIL PROTECTED]
Subject: [sqlite] How to compile a standalone wrapper?!


Hello,

i´m new to SQLite, so to learn how the engine works a.s.o i am just coding a
wrapper for VB. Now i have a question: How must i compile my project so that
my wrapper becomes standalone from SQLite? I´m using and studing C++ with
VC5 and don´t know what to do, how i must bind the sqlite.dll in my project?
Thanks for your help.

Best regards.
Sören

__
UNICEF bringt Kriegskinder in die Schule - helfen Sie mit!
https://www.unicef.de/spe/spe_03.php


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] Crystal Reports

[Steve O'Hara]

Use the SQLite ODBC driver and away you go.  I think I saw that someone has
developed an OLEDB driver for SQLite which you could also use.
Or, if you want to get a bit closer to Crystal, write your own Crystal
Datasource Driver in VB/C++

Steve

-Original Message-
From: Jeff Edwards [mailto:[EMAIL PROTECTED]
Sent: 16 December 2003 09:47
To: [EMAIL PROTECTED]@sqlite.orge.org
Subject: [sqlite] Crystal Reports


I am wondering if Crystal reports can be used with sqlite.

Can anyone give me a little knowledge about this.

Many thanks

Jeff Edwards


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] Is case sensitivity a problem for me only?

[Steve O'Hara]

Why should case sensitive data comparisons be maintained ?

It seems to me that it's only in the most obtuse examples where it is of any
use e.g. algebra, formulae, equations etc.  Even then, how many people will
search for a formula ?
However, I would agree, that there is an absolute need to maintain the case
of the actual stored data.  But we shouldn't confuse the storage of data
with the querying of data.

By forcing people to use UPPER/LOWER functions to remove the case
sensitivity, you are condemning them to considerably poorer performance.  As
I understand it, UPPER/LOWER and LIKE operators will cause SQLite NOT to use
indexes if there are any defined for the column.

As you say, Unix has a case sensitive file system (unlike Windows, DOS or
VMS for that matter) which is perhaps why the commercial RDBMS that were
developed on Unix (Informix, Oracle?, Ingress) are all case sensitive,
and the one that wasn't, SQLServer isn't.

Can't we solve this in the index ?

Steve




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 01 December 2003 22:05
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [sqlite] Is case sensitivity a problem for me only?


For ease of use and less prone to programming errors, Table/Field names
should be case INsensitive.  Of course data comparisons should be case
sensitive, and use UPPER/LOWER methods where case is not a factor.  This
is one thing Unix has taught the world with case sensitivity in its file
system - its a big mistake.  In the Windows world we *never* have bugs due
to case mistakes in programs where files are involved.  IMHO it we will be
*much* better off if Sqlite works like this.

>
>> Pavel said:
>> >Hi, all.
>> >Traditionally, SQL databases are case insensitive, or at least have an
>> >option to behave this way. Sqlite is case sensitive and this fact is
>> >introduced in a lot of places in sources. Having case-insensitive
>> >sorting and matching seem to be extremely useful thing to me (in
>> >business domain where one have to deal with names, addresses etc). Any
>> >opinions?
>> >Yours, Pavel
>>
>> Personally, I prefer that databases *are* case-sensitive by default, as
> this matches how most programming languages work.
>>
>> If I do a normal comparison between two strings in a programming
>> language,
> they match only if the case is the same.  It gives me plenty of headaches
> if
> the database behaves differently, and I can't be certain if matches
> returned
> by a database actually are matches.
>>
>> Also, case-sensitive comparisons (basis for both matching and sorting)
>> are
> considerably faster and use less memory than non-sensitive ones, since
> with
> the latter one has to convert the string on each side to either an upper
> or
> lower case representation, so that the normal numerical comparison of the
> strings match, and with the former, no conversion is needed.
>>
>> Also, in these days of increasing internationalization, it is simpler to
> do case-sensitive by default since that's what all the world's other
> character sets and our own non-letter symbols do, to my knowledge.
>>
>> Now I do recognize the value of case-insensitive comparisions, but I
>> think
> that this should be done as a type of extension functionality rather than
> in
> core functionality.
>>
>> What I mean is, have a different syntax to specify case-insensitive
> matching, much in the way that "like '%abc%'" is used when we want to
> match
> just part of a string.
>>
>> Also or alternately, treat case-insensitive operations as a
>> locale-related
> thing, much as parts of a database schema can be configured to do things
> in
> a certain way, such as sorting, based on the user's locale.
>>
>> So case-sensitive default actions all around are the simplest, fastest,
> take the least code, are the most reliable, and technically most standard
> way of doing things.  So I see SQLite doing sensitive by default as a good
> thing.
>>
>> -- Darren Duncan
>>
>> -
>> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
>> For additional commands, e-mail:
> [EMAIL PROTECTED]
>>
>>
>
>
>
> I'm in the opposite camp I'm afraid - I find case sensitivity irritating
> for
> both database and programming language and also, a little unneccersary.
> Most real world database applications have to provide some level of
> textual
> searching to their users, be it names, addresses etc.  Case sensitivity is
> a
> major pain in these circumstances.
>
> I've been working with text management systems for the last 12 years where
> this issue is normally managed on a per column basis through the index
> i.e.
> you define an index for a column to be case insensitive and the search
> terms
> are adjusted accordingly when a query is run.
> Therefore, the performance of case insensitive searching is NOT slower
> because the search terms in the index are stored in upper case - when the
> query is run, the user 

[sqlite] Listserver Digest Attachments

[Steve O'Hara]

Hi All,

I suppose this has to be the most boring topic that I've seen on SQLite
listservers for the past 2 years.  However, since the switch away from
Yahoo, it has revealed how much I relied on the communication features of
the listserver.

The new listserver is making it very difficult for me to "keep with the
programme".  I get some 50 emails per day from various sources and I can't
afford to have SQLite traffic adding to this list.  However, I do want to
get a daily digest of what's happening and to contribute if there is a topic
on which I think I can usefully comment.

I'm a Windows (followed by Unix then VMS) guy and I use Outlook to view my
email.  The digest comes in the form of categorised headers (good) and a
long list of attachments (bad).  Outlook doesn't show me the full title of
the attachments so I have to open every one of them to try and follow a
thread.  It's so off-putting, that i would un-subscribe from the list if
there were an alternative way of viewing the listserver e.g. web interface.

I can fully understand the reasons for moving away from Yahoo and I
appreciate the continued efforts of all those involved in providing the new
service. But, it's a retrograde step for me and I suspect for others too.
Okay, I might be the fool on the hill whose input isn't that useful anyway,
but I'd really like to stay involved and the new mechanism is making it hard
for me.

The "reply-to"/"replay to all" debate is too puerile to even comment
on..

Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]