Towards SQLite version 3.5.0

classic Classic list List threaded Threaded
109 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

Towards SQLite version 3.5.0

D. Richard Hipp
The transition from 3.4.2 to 3.5.0 will perhaps be the
largest single change to SQLite since 2.8->3.0.  There
will not be that many visible changes, but a lot is
changing behind the scenes.  Some less frequently used
interfaces will be changing in slightly incompatible
ways.  Users who have build customized OS intereface layers
or backends for SQLite will find that they are going to
need to do some rework.

SQLite version 3.5.0 is not close to being ready yet.
But it is to the point where the source code will
compile and pass many tests.  And so I would like to
take this opportunity to encourage people in the
community to download the CVS HEAD and give it
a whirl in their applications.  Please let me know
about any serious issues you run across.

I have *started* to prepare documentation describing
the changes in 3.5.0.  This is draft documentation.
But for those who are interested, please visit

   http://www.sqlite.org/34to35.html
   http://www.sqlite.org/capi350ref.html

In particular, if your application uses a customized
OS interface for SQLite, you should read the 34to35.html
document to see exactly what will be involved in porting
your application to run with version 3.5.0.

The SQLite code currently in CVS HEAD is not ready for
production use.  We know that.  We know what many of the
problems are and Dan and I are working long hours to fix
them.  It's the problems that we *do not* know about that
are scary.  So that is why I am inviting the larger
community to have an early look and perhaps bring our
attention to issues sooner rather than later.

--
D. Richard Hipp <[hidden email]>


-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Towards SQLite version 3.5.0

Richard Klein-3
The documentation looks great!  I look forward to the
release of 3.5.0.

A couple of questions:

(1) In 3.5.0, a database cache can be shared by two
different threads having two different database
connections.  I infer from this that two different
threads can now share a cache without having to
utilize a client/server mechanism.  True?

(2) The presence of the new mutex subsystem, and the
absence of xReadLock(), xWriteLock(), and xUnlock()
methods in the new VFS object, would seem to indicate
that SQLite has abandoned the use of file locking to
synchronize access to a shared database.  True?

(I hope so; it means that we embedded developers don't
have to spend precious development time emulating those
file locking calls.)

All in all, 3.5.0 looks to be a major improvement over
the current design.  Any idea when it might be ready?

Regards,
- Richard


[hidden email] wrote:

> The transition from 3.4.2 to 3.5.0 will perhaps be the
> largest single change to SQLite since 2.8->3.0.  There
> will not be that many visible changes, but a lot is
> changing behind the scenes.  Some less frequently used
> interfaces will be changing in slightly incompatible
> ways.  Users who have build customized OS intereface layers
> or backends for SQLite will find that they are going to
> need to do some rework.
>
> SQLite version 3.5.0 is not close to being ready yet.
> But it is to the point where the source code will
> compile and pass many tests.  And so I would like to
> take this opportunity to encourage people in the
> community to download the CVS HEAD and give it
> a whirl in their applications.  Please let me know
> about any serious issues you run across.
>
> I have *started* to prepare documentation describing
> the changes in 3.5.0.  This is draft documentation.
> But for those who are interested, please visit
>
>    http://www.sqlite.org/34to35.html
>    http://www.sqlite.org/capi350ref.html
>
> In particular, if your application uses a customized
> OS interface for SQLite, you should read the 34to35.html
> document to see exactly what will be involved in porting
> your application to run with version 3.5.0.
>
> The SQLite code currently in CVS HEAD is not ready for
> production use.  We know that.  We know what many of the
> problems are and Dan and I are working long hours to fix
> them.  It's the problems that we *do not* know about that
> are scary.  So that is why I am inviting the larger
> community to have an early look and perhaps bring our
> attention to issues sooner rather than later.
>
> --
> D. Richard Hipp <[hidden email]>
>
>
> -----------------------------------------------------------------------------
> To unsubscribe, send email to [hidden email]
> -----------------------------------------------------------------------------
>

-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Towards SQLite version 3.5.0

ken-33
In reply to this post by D. Richard Hipp
ranlib .libs/libsqlite3.a
creating libsqlite3.la
(cd .libs && rm -f libsqlite3.la && ln -s ../libsqlite3.la libsqlite3.la)
./libtool --mode=link gcc -g -O2 -I. -I../src -DNDEBUG   -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1  -DHAVE_READLINE=1 -I/usr/include/readline -lpthread  \
        -o sqlite3 ../src/shell.c libsqlite3.la \
        -lreadline -lreadline
gcc -g -O2 -I. -I../src -DNDEBUG -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DHAVE_READLINE=1 -I/usr/include/readline -o .libs/sqlite3 ../src/shell.c  ./.libs/libsqlite3.so -lpthread -lreadline
/tmp/ccFQJzGR.o: In function `dump_callback':
../src/shell.c:762: undefined reference to `sqlite3_free'
/tmp/ccFQJzGR.o: In function `run_schema_dump_query':
../src/shell.c:837: undefined reference to `sqlite3_free'
/tmp/ccFQJzGR.o: In function `do_meta_command':
../src/shell.c:1431: undefined reference to `sqlite3_free'
../src/shell.c:1491: undefined reference to `sqlite3_free'
../src/shell.c:1147: undefined reference to `sqlite3_free'
/tmp/ccFQJzGR.o:../src/shell.c:1670: more undefined references to `sqlite3_free' follow
./.libs/libsqlite3.so: undefined reference to `sqlite3_mutex_leave'
./.libs/libsqlite3.so: undefined reference to `sqlite3_mutex_try'
./.libs/libsqlite3.so: undefined reference to `sqlite3_mutex_free'
./.libs/libsqlite3.so: undefined reference to `sqlite3_memory_alarm'
./.libs/libsqlite3.so: undefined reference to `sqlite3_malloc'
./.libs/libsqlite3.so: undefined reference to `sqlite3_realloc'
./.libs/libsqlite3.so: undefined reference to `sqlite3_memory_used'
./.libs/libsqlite3.so: undefined reference to `sqlite3_mutex_alloc'
./.libs/libsqlite3.so: undefined reference to `sqlite3_mutex_enter'
collect2: ld returned 1 exit status
make: *** [sqlite3] Error 1


[hidden email] wrote: The transition from 3.4.2 to 3.5.0 will perhaps be the
largest single change to SQLite since 2.8->3.0.  There
will not be that many visible changes, but a lot is
changing behind the scenes.  Some less frequently used
interfaces will be changing in slightly incompatible
ways.  Users who have build customized OS intereface layers
or backends for SQLite will find that they are going to
need to do some rework.

SQLite version 3.5.0 is not close to being ready yet.
But it is to the point where the source code will
compile and pass many tests.  And so I would like to
take this opportunity to encourage people in the
community to download the CVS HEAD and give it
a whirl in their applications.  Please let me know
about any serious issues you run across.

I have *started* to prepare documentation describing
the changes in 3.5.0.  This is draft documentation.
But for those who are interested, please visit

   http://www.sqlite.org/34to35.html
   http://www.sqlite.org/capi350ref.html

In particular, if your application uses a customized
OS interface for SQLite, you should read the 34to35.html
document to see exactly what will be involved in porting
your application to run with version 3.5.0.

The SQLite code currently in CVS HEAD is not ready for
production use.  We know that.  We know what many of the
problems are and Dan and I are working long hours to fix
them.  It's the problems that we *do not* know about that
are scary.  So that is why I am inviting the larger
community to have an early look and perhaps bring our
attention to issues sooner rather than later.

--
D. Richard Hipp


-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: Towards SQLite version 3.5.0

D. Richard Hipp
In reply to this post by Richard Klein-3
Richard Klein <[hidden email]> wrote:

> The documentation looks great!  I look forward to the
> release of 3.5.0.
>
> A couple of questions:
>
> (1) In 3.5.0, a database cache can be shared by two
> different threads having two different database
> connections.  I infer from this that two different
> threads can now share a cache without having to
> utilize a client/server mechanism.  True?

Correct.

>
> (2) The presence of the new mutex subsystem, and the
> absence of xReadLock(), xWriteLock(), and xUnlock()
> methods in the new VFS object, would seem to indicate
> that SQLite has abandoned the use of file locking to
> synchronize access to a shared database.  True?

False.  The names of the methods are xLock() and
xUnlock() and they are found in the sqlite3_io_methods
structure.

--
D. Richard Hipp <[hidden email]>


-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Towards SQLite version 3.5.0

developir@yahoo.com
In reply to this post by D. Richard Hipp
--- [hidden email] wrote:
> The transition from 3.4.2 to 3.5.0 will perhaps be the
...
> The SQLite code currently in CVS HEAD is not ready for
> production use.  We know that.  We know what many of the
> problems are and Dan and I are working long hours to fix
> them.  It's the problems that we *do not* know about that
> are scary.  So that is why I am inviting the larger
> community to have an early look and perhaps bring our
> attention to issues sooner rather than later.

Just to clarify, you don't want to see "make test" failure
tickets at this time?



       
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC

-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Towards SQLite version 3.5.0

D. Richard Hipp
Joe Wilson <[hidden email]> wrote:

> --- [hidden email] wrote:
> > The transition from 3.4.2 to 3.5.0 will perhaps be the
> ....
> > The SQLite code currently in CVS HEAD is not ready for
> > production use.  We know that.  We know what many of the
> > problems are and Dan and I are working long hours to fix
> > them.  It's the problems that we *do not* know about that
> > are scary.  So that is why I am inviting the larger
> > community to have an early look and perhaps bring our
> > attention to issues sooner rather than later.
>
> Just to clarify, you don't want to see "make test" failure
> tickets at this time?
>

Correct.  I can figure out for myself when "make test"
fails.  Those failures are examples of things I know about.
I'm much more interested in errors that I don't know about.

--
D. Richard Hipp <[hidden email]>


-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Towards SQLite version 3.5.0

developir@yahoo.com
--- [hidden email] wrote:

> Joe Wilson <[hidden email]> wrote:
> > --- [hidden email] wrote:
> > > The transition from 3.4.2 to 3.5.0 will perhaps be the
> > ....
> > > The SQLite code currently in CVS HEAD is not ready for
> > > production use.  We know that.  We know what many of the
> > > problems are and Dan and I are working long hours to fix
> > > them.  It's the problems that we *do not* know about that
> > > are scary.  So that is why I am inviting the larger
> > > community to have an early look and perhaps bring our
> > > attention to issues sooner rather than later.
> >
> > Just to clarify, you don't want to see "make test" failure
> > tickets at this time?
>
> Correct.  I can figure out for myself when "make test"
> fails.  Those failures are examples of things I know about.
> I'm much more interested in errors that I don't know about.

http://en.wikipedia.org/wiki/Unknown_unknown


       
____________________________________________________________________________________
Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/

-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Towards SQLite version 3.5.0

Dennis Cote
In reply to this post by D. Richard Hipp
[hidden email] wrote:

> The transition from 3.4.2 to 3.5.0 will perhaps be the
> largest single change to SQLite since 2.8->3.0.  
>  
> I have *started* to prepare documentation describing
> the changes in 3.5.0.  This is draft documentation.
> But for those who are interested, please visit
>
>    http://www.sqlite.org/34to35.html
>    http://www.sqlite.org/capi350ref.html
>
>
>
>  
Richard,

The API function sqlite3_vfs_find() is documented as:

> The *sqlite3_vfs_find()* API is used to locate a particular VFS by
> name. Its prototype is as follows:
>
>     sqlite3_vfs *sqlite3_vfs_find(const char *zVfsName);
>
>
> The argument is the symbolic name for the desired VFS. If the argument
> is a NULL pointer, then the default VFS is returned. The function
> returns a pointer to the *sqlite3_vfs* object that implements the VFS.
> Or it returns a NULL pointer if no object could be found that matched
> the search criteria.
>
>

I wonder if it might not be better to change this API to accept an empty
string, in addition to a NULL pointer, to find the default VFS. It seems
to me this might make life easier for those writing wrappers in
languages that don't have a concept of a NULL pointer.

Dennis Cote

-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Towards SQLite version 3.5.0

Klemens Friedl
In reply to this post by developir@yahoo.com
The "sqlite3_exec" function has resided in the "legacy.c" file since
shift to version 3. The function is still around in current v3.5 draft
as http://www.sqlite.org/capi350ref.html says.

That function is still kept around for compatibility reasons, as it
was a important function in SQLite v2 days.
On the other side it is quite handy to execute e.g. "create", and
generally for queries that modify the database and don't return data.

Will it stay around for the whole life-span of version 3? Currently, I
prefer to avoid "sqlite3_exec" function, as it's in the "legacy.c"
file and I am unsure about its future.

The official SQLite 3 API documentation says nothing about the legacy
status of the "sqlite3_exec" function:
http://www.sqlite.org/capi3ref.html#sqlite3_exec
... nor any info in the source code, and I haven't found any
information about it beside a short footnote in "The Definitive Guide
to SQLite" book and the "legacy.c" filename in the source code.

My propose, either move function out of legacy file or add some legacy
information text to API documentation (or at least to the source code)
and about its planned life span.




About mutex usage, the following page
http://www.sqlite.org/34to35.html mentions :
"[...] The SQLite source code provides multiple implementations of
these APIs, suitable for varying environments. [...]"
"[...] Embedded applications may wish to provide their own mutex
implementation. [...]"

For Unix, the POSIX Pthreads specification supports mutexes. The four
basic functions are as follows:
* pthread_mutex_init
* pthread_mutex_destory
* ptrhead_mutex_lock
* pthread_mutex_unlock

In Win32 world, the same can be solved by using Win32 Mutex functions
or CRITICAL_SECTIONS (beside others):
* CreateMutex
* ReleaseMutex
* OpenMutex

SQLite 3 already use Win32 Mutex for WinCE (file) locking ("os_win.c"
file). Most of that code could be reused for WinNT Win32 API (with the
help of some macros, because of the "wince" part of the WinAPI
function names).

Will SQLite 3.5 use operating system related mutex API or does it ship
with its own mutex implemented functions (I have seen some related
code, but haven't investigated further)?

-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Towards SQLite version 3.5.0

Marco Bambini
In reply to this post by Dennis Cote
On Aug 28, 2007, at 4:51 PM, Dennis Cote wrote:

> I wonder if it might not be better to change this API to accept an  
> empty string, in addition to a NULL pointer, to find the default  
> VFS. It seems to me this might make life easier for those writing  
> wrappers in languages that don't have a concept of a NULL pointer.
>
> Dennis Cote


Just pass 0 in that case.

---
Marco Bambini
http://www.sqlabs.net
http://www.sqlabs.net/blog/
http://www.sqlabs.net/realsqlserver/

-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Towards SQLite version 3.5.0

developir@yahoo.com
In reply to this post by Dennis Cote
--- Dennis Cote <[hidden email]> wrote:

> >     sqlite3_vfs *sqlite3_vfs_find(const char *zVfsName);
> >
> >
> > The argument is the symbolic name for the desired VFS. If the argument
> > is a NULL pointer, then the default VFS is returned. The function
> > returns a pointer to the *sqlite3_vfs* object that implements the VFS.
> > Or it returns a NULL pointer if no object could be found that matched
> > the search criteria.
> >
> >
>
> I wonder if it might not be better to change this API to accept an empty
> string, in addition to a NULL pointer, to find the default VFS. It seems
> to me this might make life easier for those writing wrappers in
> languages that don't have a concept of a NULL pointer.

That's an issue for the wrapper language binding, not the language itself.
The wrapper language binding can call a null pointer whatever it wants.


       
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC

-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Towards SQLite version 3.5.0

D. Richard Hipp
In reply to this post by Dennis Cote
Dennis Cote <[hidden email]> wrote:
>
> I wonder if it might not be better to change this API to accept an empty
> string, in addition to a NULL pointer, to find the default VFS. It seems
> to me this might make life easier for those writing wrappers in
> languages that don't have a concept of a NULL pointer.
>

I'll meet you half way.  I have changed the sqlite3_vfs_register()
documentation to make the behavior undefined if you try to
register a VFS with a name that an empty string.

This way, you can be certain that no valid VFS has an empty
string as its name.  And your wrapper can map empty string
into NULL.

--
D. Richard Hipp <[hidden email]>


-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Towards SQLite version 3.5.0

Eugene Wee
In reply to this post by D. Richard Hipp
Would this be a good time to replace the older sqlite3_prepare() and
sqlite3_prepare16() interfaces with what is currently the newer
sqlite3_prepare_v2() and sqlite3_prepare16_v2() interfaces respectively?
Admittedly they are definitely not among the "less frequently used
interfaces", but such an incompatible change to existing interfaces
would be best done in such a version number jump if it is ever intended.

Regards,
Eugene Wee

[hidden email] wrote:

> The transition from 3.4.2 to 3.5.0 will perhaps be the
> largest single change to SQLite since 2.8->3.0.  There
> will not be that many visible changes, but a lot is
> changing behind the scenes.  Some less frequently used
> interfaces will be changing in slightly incompatible
> ways.  Users who have build customized OS intereface layers
> or backends for SQLite will find that they are going to
> need to do some rework.
>
> SQLite version 3.5.0 is not close to being ready yet.
> But it is to the point where the source code will
> compile and pass many tests.  And so I would like to
> take this opportunity to encourage people in the
> community to download the CVS HEAD and give it
> a whirl in their applications.  Please let me know
> about any serious issues you run across.
>
> I have *started* to prepare documentation describing
> the changes in 3.5.0.  This is draft documentation.
> But for those who are interested, please visit
>
>    http://www.sqlite.org/34to35.html
>    http://www.sqlite.org/capi350ref.html
>
> In particular, if your application uses a customized
> OS interface for SQLite, you should read the 34to35.html
> document to see exactly what will be involved in porting
> your application to run with version 3.5.0.
>
> The SQLite code currently in CVS HEAD is not ready for
> production use.  We know that.  We know what many of the
> problems are and Dan and I are working long hours to fix
> them.  It's the problems that we *do not* know about that
> are scary.  So that is why I am inviting the larger
> community to have an early look and perhaps bring our
> attention to issues sooner rather than later.
>
> --
> D. Richard Hipp <[hidden email]>
>
>
> -----------------------------------------------------------------------------
> To unsubscribe, send email to [hidden email]
> -----------------------------------------------------------------------------
>


-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Towards SQLite version 3.5.0

Daniel Önnerby
In reply to this post by D. Richard Hipp
Hi!

The new multithread-features will be great.
Do you think that it will be better to share one connection between all
theads in an application or is better to have each thread open a new
connection and use the sqlite3_enable_shared_cache?

Best regards
Daniel

[hidden email] wrote:

> The transition from 3.4.2 to 3.5.0 will perhaps be the
> largest single change to SQLite since 2.8->3.0.  There
> will not be that many visible changes, but a lot is
> changing behind the scenes.  Some less frequently used
> interfaces will be changing in slightly incompatible
> ways.  Users who have build customized OS intereface layers
> or backends for SQLite will find that they are going to
> need to do some rework.
>
> SQLite version 3.5.0 is not close to being ready yet.
> But it is to the point where the source code will
> compile and pass many tests.  And so I would like to
> take this opportunity to encourage people in the
> community to download the CVS HEAD and give it
> a whirl in their applications.  Please let me know
> about any serious issues you run across.
>
> I have *started* to prepare documentation describing
> the changes in 3.5.0.  This is draft documentation.
> But for those who are interested, please visit
>
>    http://www.sqlite.org/34to35.html
>    http://www.sqlite.org/capi350ref.html
>
> In particular, if your application uses a customized
> OS interface for SQLite, you should read the 34to35.html
> document to see exactly what will be involved in porting
> your application to run with version 3.5.0.
>
> The SQLite code currently in CVS HEAD is not ready for
> production use.  We know that.  We know what many of the
> problems are and Dan and I are working long hours to fix
> them.  It's the problems that we *do not* know about that
> are scary.  So that is why I am inviting the larger
> community to have an early look and perhaps bring our
> attention to issues sooner rather than later.
>
> --
> D. Richard Hipp <[hidden email]>
>
>
> -----------------------------------------------------------------------------
> To unsubscribe, send email to [hidden email]
> -----------------------------------------------------------------------------
>
>  


-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

BestMatch and SqliteStatment Clash

RaghavendraK 70574
Hi,

create table test (t text);

insert into test values ('9');
insert into test values ('98');
insert into test values ('986');
insert into test values ('9867');

select * from test where '98555'  like t || '%' order by t desc limit 1;

When we try to compile the above sql as a statement,we get Success but
when we bind it gives a error "SQLITE_RANGE".
After inspection we find
"sParse.nVar" = 0 [which represent nr of  "?"]

Can u pls help to correct this error.


regards
ragha


******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: Daniel Önnerby <[hidden email]>
Date: Wednesday, August 29, 2007 4:20 pm
Subject: Re: [sqlite] Towards SQLite version 3.5.0

> Hi!
>
> The new multithread-features will be great.
> Do you think that it will be better to share one connection
> between all
> theads in an application or is better to have each thread open a
> new
> connection and use the sqlite3_enable_shared_cache?
>
> Best regards
> Daniel
>
> [hidden email] wrote:
> > The transition from 3.4.2 to 3.5.0 will perhaps be the
> > largest single change to SQLite since 2.8->3.0.  There
> > will not be that many visible changes, but a lot is
> > changing behind the scenes.  Some less frequently used
> > interfaces will be changing in slightly incompatible
> > ways.  Users who have build customized OS intereface layers
> > or backends for SQLite will find that they are going to
> > need to do some rework.
> >
> > SQLite version 3.5.0 is not close to being ready yet.
> > But it is to the point where the source code will
> > compile and pass many tests.  And so I would like to
> > take this opportunity to encourage people in the
> > community to download the CVS HEAD and give it
> > a whirl in their applications.  Please let me know
> > about any serious issues you run across.
> >
> > I have *started* to prepare documentation describing
> > the changes in 3.5.0.  This is draft documentation.
> > But for those who are interested, please visit
> >
> >    http://www.sqlite.org/34to35.html
> >    http://www.sqlite.org/capi350ref.html
> >
> > In particular, if your application uses a customized
> > OS interface for SQLite, you should read the 34to35.html
> > document to see exactly what will be involved in porting
> > your application to run with version 3.5.0.
> >
> > The SQLite code currently in CVS HEAD is not ready for
> > production use.  We know that.  We know what many of the
> > problems are and Dan and I are working long hours to fix
> > them.  It's the problems that we *do not* know about that
> > are scary.  So that is why I am inviting the larger
> > community to have an early look and perhaps bring our
> > attention to issues sooner rather than later.
> >
> > --
> > D. Richard Hipp <[hidden email]>
> >
> >
> > -----------------------------------------------------------------
> ------------
> > To unsubscribe, send email to [hidden email]
> > -----------------------------------------------------------------
> ------------
> >
> >  
>
>
> -------------------------------------------------------------------
> ----------
> To unsubscribe, send email to [hidden email]
> -------------------------------------------------------------------
> ----------
>
>

-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: BestMatch and SqliteStatment Clash

Dan Kennedy-4
On Wed, 2007-08-29 at 16:43 +0800, RaghavendraK 70574 wrote:

> Hi,
>
> create table test (t text);
>
> insert into test values ('9');
> insert into test values ('98');
> insert into test values ('986');
> insert into test values ('9867');
>
> select * from test where '98555'  like t || '%' order by t desc limit 1;

There are no SQL variables to bind to in that statement. Syntax
for SQL variables is here:

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

Dan.



-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: BestMatch and SqliteStatment Clash

RaghavendraK 70574
Hi,

Am using sqlite 3.4.0

stmt= sqlite_prepareV2("select * from test where '?'  like t || '%' order by t desc);
? is the sql variable.
This is not the normal sql statement.I have reversed the columnName and Value.Normally
it will be where columnName like 'value%'

stmt.bind(1&#65292;'98455'); //i get error here [sqlite_range]

regards
ragha
******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: Dan Kennedy <[hidden email]>
Date: Wednesday, August 29, 2007 6:13 pm
Subject: Re: [sqlite] BestMatch and SqliteStatment Clash

> On Wed, 2007-08-29 at 16:43 +0800, RaghavendraK 70574 wrote:
> > Hi,
> >
> > create table test (t text);
> >
> > insert into test values ('9');
> > insert into test values ('98');
> > insert into test values ('986');
> > insert into test values ('9867');
> >
> > select * from test where '98555'  like t || '%' order by t desc
> limit 1;
>
> There are no SQL variables to bind to in that statement. Syntax
> for SQL variables is here:
>
>  http://www.sqlite.org/lang_expr.html
>
> Dan.
>
>
>
> -------------------------------------------------------------------
> ----------
> To unsubscribe, send email to [hidden email]
> -------------------------------------------------------------------
> ----------
>
>

-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: BestMatch and SqliteStatment Clash

John Machin
On 29/08/2007 8:37 PM, RaghavendraK 70574 wrote:
> Hi,
>
> Am using sqlite 3.4.0
>
> stmt= sqlite_prepareV2("select * from test where '?'  like t || '%' order by t desc);
> ? is the sql variable.

No it isn't; it's the contents of a string constant.
Try this:
select * from test where ? like t || '%' order by t desc

-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: BestMatch and SqliteStatment Clash

Dan Kennedy-4
In reply to this post by RaghavendraK 70574
On Wed, 2007-08-29 at 18:37 +0800, RaghavendraK 70574 wrote:
> Hi,
>
> Am using sqlite 3.4.0
>
> stmt= sqlite_prepareV2("select * from test where '?'  like t || '%' order by t desc);

You need to remove the ' quotes around the question mark.
At the moment the expression is a literal string value,
not an sql variable.




-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: BestMatch and SqliteStatment Clash

RaghavendraK 70574
Thx. I have modifed it to ?, but
Sqlite fails to get records for the below query. When debug it retuns
SQLITE_DONE. Pls help.

select * from 'tbl.7' where ? like column1 || '%' order by column1 desc limit 1;

Data is as below:
Version: 3.4.0
Re-confirm the problem in sqlite and not in my code,
I tried using sqlite3 commandLine tool and found the same problem.

create table 'tbl.7'(ver integer,
                     column1 text not NULL,
                     column2 text not NULL,
                     column3 text not NULL,
                     column4 text not NULL,
                     column5 text not NULL,
      column6 text not NULL,
                     column7 text not NULL,
                     column8 text not NULL,
                     column9 text not NULL,
                     column10 text not NULL,
                     primary key(ver,column1,column2,column3,column4,column5));


insert into 'tbl.7'
values
(7,
'9845002655',
'9845002655',
'9845002655',
'9845002655',
'9845002655',
'COLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL',
'COLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL',
'COLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL',
'COLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL',
'COLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL');

insert into 'tbl.7'
values
(7,
'9854002656',
'9845002655',
'9845002655',
'9845002655',
'9845002655',
'COLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL',
'COLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL',
'COLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL',
'COLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL',
'COLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL');

--Best match for 985
select * from 'tbl.7' where '985' like column1 || '%' order by column1 desc limit 1;


regards
ragha

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: Dan Kennedy <[hidden email]>
Date: Wednesday, August 29, 2007 7:07 pm
Subject: Re: [sqlite] BestMatch and SqliteStatment Clash

> On Wed, 2007-08-29 at 18:37 +0800, RaghavendraK 70574 wrote:
> > Hi,
> >
> > Am using sqlite 3.4.0
> >
> > stmt= sqlite_prepareV2("select * from test where '?'  like t ||
> '%' order by t desc);
>
> You need to remove the ' quotes around the question mark.
> At the moment the expression is a literal string value,
> not an sql variable.
>
>
>
>
> -------------------------------------------------------------------
> ----------
> To unsubscribe, send email to [hidden email]
> -------------------------------------------------------------------
> ----------
>
>

-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

1234 ... 6