Re: [sqlite] Re: Number of rows in a query result

[Puneet Kishor]

On Oct 31, 2005, at 7:54 PM, Edward Wilson wrote:


I simply count the number of elements in my record set
thereby avoiding a double query to the database.


Yes, exactly, I take for granted that the resultset is accumulated at 
the database level and not

at the application level.


sorry, I don't quite understand what you imply by the above. Obviously 
this discussion stems from the fact that you can't take that for 
granted, at least not without paying some cost for it. Because I don't 
want to tie up the db doing double queries, I just do it in the 
application.







-
ed

--- Puneet Kishor <[EMAIL PROTECTED]> wrote:



On Oct 28, 2005, at 7:20 PM, SRS wrote:


Edward Wilson wrote:


The idea of issuing two selects is, well, a hack, and knowing how
many records one has in a
result-set is a powerful feature



Are you needing a progress bar for the search (ie the query?) Or some
action based on the result set?  If the later, get the result set as
your favorite container.. ask the container the size.  If its the
first then a "feature" won't help.  It still has to 'run' the query 
in
order to get the count.  It would be like me asking you to tell me 
how

many red Skittles are in a package before you open it. As for being a
'hack' .. all your 'feature' would be is a pretty programming
interface around that hack.  As I said before, how can the database
know the number of items that will be returned without first 
searching

for them.



I think the problem is not so much (at least IMHO) that two queries
have to be performed (that itself is a reasonable expectation), but
that the COUNT(*) query is likely to be slow because of the full table
scan. One option is to use an aftermarket solution... for example, in
my Perl applications once I have queried the db for the columns based
on my criteria, I simply count the number of elements in my record set
thereby avoiding a double query to the database. Although, in reality,
I personally don't mind the COUNT(*) option... none of my databases 
are

that large to merit worrying about this.







__
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs

Re: [sqlite] Re: Number of rows in a query result

[Edward Wilson]

>I simply count the number of elements in my record set 
>thereby avoiding a double query to the database.

Yes, exactly, I take for granted that the resultset is accumulated at the 
database level and not
at the application level.


-
ed

--- Puneet Kishor <[EMAIL PROTECTED]> wrote:

> 
> On Oct 28, 2005, at 7:20 PM, SRS wrote:
> 
> > Edward Wilson wrote:
> >
> >> The idea of issuing two selects is, well, a hack, and knowing how 
> >> many records one has in a
> >> result-set is a powerful feature
> >>
> >
> > Are you needing a progress bar for the search (ie the query?) Or some 
> > action based on the result set?  If the later, get the result set as 
> > your favorite container.. ask the container the size.  If its the 
> > first then a "feature" won't help.  It still has to 'run' the query in 
> > order to get the count.  It would be like me asking you to tell me how 
> > many red Skittles are in a package before you open it. As for being a 
> > 'hack' .. all your 'feature' would be is a pretty programming 
> > interface around that hack.  As I said before, how can the database 
> > know the number of items that will be returned without first searching 
> > for them.
> >
> 
> I think the problem is not so much (at least IMHO) that two queries 
> have to be performed (that itself is a reasonable expectation), but 
> that the COUNT(*) query is likely to be slow because of the full table 
> scan. One option is to use an aftermarket solution... for example, in 
> my Perl applications once I have queried the db for the columns based 
> on my criteria, I simply count the number of elements in my record set 
> thereby avoiding a double query to the database. Although, in reality, 
> I personally don't mind the COUNT(*) option... none of my databases are 
> that large to merit worrying about this.
> 
> 




__ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs

Re: [sqlite] Handling dates and timestamps via the C API

[John Stanton]

We use a TEXT field for dates and time and make it strictly ISO8601 and 
hence portable between storage methods.


Jay Sprenkle wrote:

I would like to know how I should handle dates and timestamps
via the C API. I know that if I write an SQL insert statement, I have
to use one of the forms reserved for dates and timestamps and
the like, but how do I do this via the sqlite3_bind_* procedures?



I treat dates as a text field and have a C++ class that deals with all
the abstractions
of a date.

[sqlite] tclsqlite.c DB_COPY: binary mode?

[Andy Goth]

Is it really necessary for copy's input file to be fopen()ed with mode
"rb"?  This causes CRLF files opened on MS-Windows to have \r's appended
to the values in the last column.  The last column might otherwise be
numeric.

Actually, I'd prefer that DB_COPY accept a Tcl channel rather than a
filename.  (Of course, let's not break existing code.)  This way Tcl can
handle all the encoding and line ending junk, plus I can [seek] past
(okay, [gets] past) any header lines.  Moreover, this will make using
stdin possible (I read the header line, sqlite3's DB_COPY reads the
rest, and there's no seeking and no reopening).

-- 
Andy Goth
   <[EMAIL PROTECTED]>
   <[EMAIL PROTECTED]>


signature.asc
Description: OpenPGP digital signature

[sqlite] Re: OCaml binding for SQLite 3

[Toby Allsopp]

On 30 Oct 2005 at 03:14 NZST, Florian Weimer wrote:

> Is it true that there isn't yet a binding to SQLite versoin 3 from
> Objective Caml?
>
> (I only found one for version 2.)

There seem to be a couple of different ocaml-sqlite3 bindings around:

http://www.imada.sdu.dk/~bardur/personal/45-programs/ocaml-sqlite3/
http://metamatix.org/~ocaml/ocaml_sqlite3.html

I found these by typing "ocaml-sqlite3" into Google.  I haven't used
either.

Regards,
Toby.

[sqlite] Handling dates and timestamps via the C API

[Arjen Markus]

Hello,

I would like to know how I should handle dates and timestamps 
via the C API. I know that if I write an SQL insert statement, I have
to use one of the forms reserved for dates and timestamps and
the like, but how do I do this via the sqlite3_bind_* procedures?

Regards,

Arjen

Re: [sqlite] built-in functrion suggestion: size of blob

[Joe Wilson]

Oops - the second paragraph should have read:
"with appropriate manipulations of sqlite3_value_type(), 
sqlite3_value_bytes() and sqlite3_value_text()."

--- Joe Wilson <[EMAIL PROTECTED]> wrote:

> Length() is perfectly consistant with the value's type. As you've 
> demonstrated, Sqlite does not respect the column types in tables 
> as declared in the CREATE statement.
> Length(text_value) always returns the number of characters and 
> length(blob_value) always returns the number of bytes. The type 
> of the value depends solely on its type at the time of INSERT 
> or UPDATE. I believe the Sqlite author calls this feature 
> "manifest typing".
> 
> When coding in C you can easily get the number of bytes in a TEXT 
> or BLOB value with appropriate manipulations of sqlite3_value_type(), 
> sqlite3_result_int() and sqlite3_result_text(). So no problem there.
> 
> I do not think that Sqlite SQL writers (i.e., non-C progammers) care 
> to know the number of bytes their objects take as long as their 
> assignments and comparison operations work within the framework of 
> the SQL language. 'Bytes' is more of a low-level C concept. But if 
> for some reason you absolutely must need to know the number of bytes 
> that a text or blob value takes from within the Sqlite SQL language, 
> just refer to the documentation of typeof(), CAST, CASE and quote() 
> and you can come up with a pure Sqlite SQL solution if you really 
> wanted to.
> 




__ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Re: [sqlite] Dotnet C# support

[Arjen Markus]

Robert Simpson wrote:
> 
> That's exactly what I ended up doing in the ADO.NET 2.0 wrapper.  In order
> to implement full Compact Framework support and callbacks, I ended up
> writing stdcall entrypoints and callback wrappers for just about the entire
> SQLite API.
> 

My Fortran interface does something similar, I have done it that way to
hide
the gory (and platform-dependent) details of passing parameters of the
correct 
type to the SQLite C functions. On Windows I compile SQLite as a DLL -
that
takes care of the stdcall/cdecl issue.

Regards,

Arjen

RE: [sqlite] SQLite as a Windows kernel tool

[Fred Williams]

I'm certainly not diplomatic material.  But, what you have said is
exactly what I meant.  I get more than a little weary of people who take
"free" code and whine about it. My belief is if you don't like it, fix
it yourself or shut up after your initial "notification" of the issue.

As to calling Bill's little company "Mickeysoft", I bought my first PC
the month of the introduction and have used Microsoft's products ever
since.  I think I have earned and paid enough to call Bill's company
anything I want.

Unfortunately I have watched more that one superior software technology
succumb to the steamroller that has become Microsoft.  And, it bothers
me to once again see marketing exceed over functionality (Anybody old
enough to remember IBM and the seven dwarfs?).  So, sorry if you don't
like my choice of names.

Let's not waste any more bandwidth here.  If you wish to respond, my
email address is in the header

Fred


> -Original Message-
> From: John Stanton [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 31, 2005 8:28 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] SQLite as a Windows kernel tool
>
>
> What is important is the implication of the compile warnings.
>  I agree
> that they should not be ignored, but they should be understood.  For
> example we always take pains to remove all compiler warnings,
> even the
> innocuous and gratuitous ones, so that "noise" does not hide a
> significant warning.
>
> It should not be too much trouble for you to go through Sqlite and
> remove the gratuitous warnings and then investigate any
> remaining.  It
> would be a useful contribution to the cause and does make a
> contribution
> to "zero defect" quality.
>
> We find that just indiscriminately casting can do more harm
> than good.
> Working on the underlying types to achieve consistency is better,
> otherwise you end up with a dog's breakfast like the Win32 API.
> JS
>
> Nuno Lucas wrote:
> > On 10/31/05, Fred Williams <[EMAIL PROTECTED]> wrote:
> >
> >>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.
> >
> >
> > If you forget about "Mickeysoft's latest and greatest" and only
> > consider GNU C compiler will that make you change your mind?
> >
> > gcc 3.3 and 3.4 compile without warnings, but 4.0 is a lot
> more picky
> > even without -Wall.
> >
> > For people like me that always enable all warnings, it
> makes it a must
> > to compile sqlite as a library, because it's a nightmare to use it
> > "embebed".
> >
> > I still love sqlite, it's just a feature request, nothing
> more, nothing less.
> >
> > As an example, I downloaded the preprocessed code, removed
> tclsqlite.c, and:
> >
> > [EMAIL PROTECTED]:~/src/sqlite$ gcc-4.0 *.c
> > alter.c: In function 'renameTableFunc':
> > alter.c:50: warning: pointer targets in initialization
> differ in signedness
> > alter.c:61: warning: pointer targets in assignment differ
...

Re: [sqlite] Re: Number of rows in a query result

[Jay Sprenkle]

I had this same problem some time ago. We were trying to make a virtual list
box that could handle ANY number of items. The scroll bar is the wrinkle. You
can't set it or size it without knowing the size of the list.

My conclusion was this:

A list of more than 100 or so items on screen is really useless for humans.
It's so long nobody will read the entire thing. It's good enough to present what
you can load into memory (and you can count this result set easily).

We eliminated the need for this because in reality it wasn't very useful.

"When in doubt, chop it out."

Re: [sqlite] built-in functrion suggestion: size of blob

[Joe Wilson]

Length() is perfectly consistant with the value's type. As you've 
demonstrated, Sqlite does not respect the column types in tables 
as declared in the CREATE statement.
Length(text_value) always returns the number of characters and 
length(blob_value) always returns the number of bytes. The type 
of the value depends solely on its type at the time of INSERT 
or UPDATE. I believe the Sqlite author calls this feature 
"manifest typing".

When coding in C you can easily get the number of bytes in a TEXT 
or BLOB value with appropriate manipulations of sqlite3_value_type(), 
sqlite3_result_int() and sqlite3_result_text(). So no problem there.

I do not think that Sqlite SQL writers (i.e., non-C progammers) care 
to know the number of bytes their objects take as long as their 
assignments and comparison operations work within the framework of 
the SQL language. 'Bytes' is more of a low-level C concept. But if 
for some reason you absolutely must need to know the number of bytes 
that a text or blob value takes from within the Sqlite SQL language, 
just refer to the documentation of typeof(), CAST, CASE and quote() 
and you can come up with a pure Sqlite SQL solution if you really 
wanted to.


--- Nuno Lucas <[EMAIL PROTECTED]> wrote:

> On 10/28/05, Joe Wilson <[EMAIL PROTECTED]> wrote:
> > --- Nuno Lucas <[EMAIL PROTECTED]> wrote:
> > > On 10/25/05, Joe Wilson <[EMAIL PROTECTED]> wrote:
> > > > The built-in Sqlite length() function works just fine on blobs:
> > > >
> > > >   sqlite> select length(X'00');
> > > >   5
> > > >
> > > > Why do you think it doesn't?
> > >
> > > I remember a few months ago noticing it would count UTF-8 chars, not
> > > bytes, so it would not return the right length for blobs in all cases
> > > (a '\0' is a valid UTF-8 char, but try with the '(c)' [copyright] sign,
> > > which is 2 bytes).
> > >
> > > I don't have the code in front of me, and can be just my memory, but I
> > > don't see that behaviour changing or would break a lot of SQL during
> > > normal text manipulation.
> > >
> > > Regards,
> > > ~Nuno Lucas
> >
> > You are mistaken. Text and blobs are different.
> > TEXT is of type "SQLITE_TEXT". BLOB is of type "SQLITE_BLOB".
> > length() has always correctly returned the size of a blob - look at the 
> > code:
> >
> 
> [EMAIL PROTECTED]:~/src/sqlite$ sqlite3 test.db3
> SQLite version 3.2.1
> Enter ".help" for instructions
> sqlite> create table x ( a TEXT, b BLOB );
> sqlite> insert into x values ( 'N�o', 'N�o' );
> sqlite> select * from x;
> N�o|N�o
> sqlite> select length(a), length(b) from x;
> 3|3
> sqlite> .q
> [EMAIL PROTECTED]:~/src/sqlite$ hexdump -c test.db3
> 000   S   Q   L   i   t   e   f   o   r   m   a   t   3  \0
> 010 004  \0 001 001  \0   @  \0  \0  \0 002  \0  \0  \0  \0
> 020  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0 001  \0  \0  \0 001
> 030  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0 001  \0  \0  \0  \0
> 040  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
> *
> 060  \0  \0  \0  \0  \r  \0  \0  \0 001 003 317  \0 003 317  \0  \0
> 070  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
> *
> 3c0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0   /
> 3d0 001 006 027 017 017 001   O   t   a   b   l   e   x   x 002   C
> 3e0   R   E   A   T   E   T   A   B   L   E   x   (
> 3f0   a   T   E   X   T   ,   b   B   L   O   B   )
> 400  \r  \0  \0  \0 001 003 363  \0 003 363  \0  \0  \0  \0  \0  \0
> 410  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
> *
> 7f0  \0  \0  \0  \v 001 003 025 025   N 303 243   o   N 303 243   o
> 800
> 
> As you see from the hexdump, "N�o" is encoded as UTF-8.
> 
> It's true it works if you insert a literal BLOB, like with
> x'00112233', but it only means sqlite lacks a byte counting function
> for the general case.
> 
> I don't complain about it, as I only use the SQLite C API, but it
> means there is no coherency if different programs are used to
> manipulate the database (that could insert the data in different
> ways).
> 
> Also note that I've seen a lot of sqlite wrappers/managers in the past
> that don't care the encoding used (still many people think they can
> live with only the first 127 ASCII chars), inserting Latin-1 or others
> literally, making the length function returning the wrong value when
> accented chars or other symbols - like the (c) symbol - are found. It
> would be nice if we could make a quick sanity check on the DB by
> comparing the byte count against the string length.
> 
> For me, it's just a low priority feature request, but I believe there
> are others who may think otherwise.
> 
> 
> Regards,
> ~Nuno Lucas
> 
> 
> > /*
> > ** Implementation of the length() function
> > */
> > static void lengthFunc(
> >   sqlite3_context *context,
> >   int argc,
> >   sqlite3_value **argv
> > ){
> >   int len;
> >
> >   assert( argc==1 );

Re: [sqlite] SQLite as a Windows kernel tool

[Brass Tilde]

> 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.

It's not a "nit-pic[sic]" when one's compiler (and I saw no mention of
the compiler vendor in the original poster's note, but I don't have the
start of the thread) issues a warning about potentially unsafe
behaviour.  There's a reason those warnings are issued.  Such issues can
cause hard to find problems in programs.  Code review is a valuable tool
in software development.

I believe the original poster's intent was to note that if an implicit
conversion is correct for that section of code, then what is the
down-side of changing those to explicit casts?  I'm aware that the time
spent chasing them down and analyzing each one is a major task, but I
get the impression that the OP doesn't feel qualified to make those
changes, otherwise he would have tackled it.

I believe he intended to bring the subject to the attention of DRH, in
case these are actual problems, not to "whine" about the code base.

> us all, and won't come off as such an irritating whiner.

As opposed to...?

Brad

Re: [sqlite] Dotnet C# support

[Robert Simpson]

That's exactly what I ended up doing in the ADO.NET 2.0 wrapper.  In order 
to implement full Compact Framework support and callbacks, I ended up 
writing stdcall entrypoints and callback wrappers for just about the entire 
SQLite API.


Robert


- Original Message - 
From: "Arjen Markus" <[EMAIL PROTECTED]>

To: 
Sent: Monday, October 31, 2005 12:28 AM
Subject: Re: [sqlite] Dotnet C# support



Robert Simpson wrote:






Lots of problems here ... My VB is rusty, but here goes:

1.  Don't bother declaring the callback struct -- you cannot do any form 
of
callbacks in .NET with SQLite without major hacking.  SQLite's callbacks 
are
expected to be "cdecl" and .NET callbacks are always "stdcall" and you 
will

get stack errors if you even attempt it.  The ADO.NET 2.0 provider for
SQLite does it, but I had to go through hoops.



Hm, this mismatch in calling convention could be solved by one or two
little wrapper
functions, couldn't it? I am not very familiar with .NET, so I could be
all wrong.

Regards,

Arjen

Re: [sqlite] SQLite as a Windows kernel tool

[John Stanton]

What is important is the implication of the compile warnings.  I agree 
that they should not be ignored, but they should be understood.  For 
example we always take pains to remove all compiler warnings, even the 
innocuous and gratuitous ones, so that "noise" does not hide a 
significant warning.


It should not be too much trouble for you to go through Sqlite and 
remove the gratuitous warnings and then investigate any remaining.  It 
would be a useful contribution to the cause and does make a contribution 
to "zero defect" quality.


We find that just indiscriminately casting can do more harm than good. 
Working on the underlying types to achieve consistency is better, 
otherwise you end up with a dog's breakfast like the Win32 API.

JS

Nuno Lucas wrote:

On 10/31/05, Fred Williams <[EMAIL PROTECTED]> wrote:


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.



If you forget about "Mickeysoft's latest and greatest" and only
consider GNU C compiler will that make you change your mind?

gcc 3.3 and 3.4 compile without warnings, but 4.0 is a lot more picky
even without -Wall.

For people like me that always enable all warnings, it makes it a must
to compile sqlite as a library, because it's a nightmare to use it
"embebed".

I still love sqlite, it's just a feature request, nothing more, nothing less.

As an example, I downloaded the preprocessed code, removed tclsqlite.c, and:

[EMAIL PROTECTED]:~/src/sqlite$ gcc-4.0 *.c
alter.c: In function 'renameTableFunc':
alter.c:50: warning: pointer targets in initialization differ in signedness
alter.c:61: warning: pointer targets in assignment differ in signedness
alter.c:69: warning: pointer targets in passing argument 1 of
'sqlite3GetToken' differ in signedness
alter.c: In function 'renameTriggerFunc':
alter.c:99: warning: pointer targets in initialization differ in signedness
alter.c:111: warning: pointer targets in assignment differ in signedness
alter.c:119: warning: pointer targets in passing argument 1 of
'sqlite3GetToken' differ in signedness
alter.c: In function 'sqlite3AlterFinishAddColumn':
alter.c:445: warning: pointer targets in passing argument 1 of
'sqlite3StrNDup' differ in signedness
btree.c: In function 'unlockBtreeIfUnused':
btree.c:1537: warning: pointer targets in assignment differ in signedness
build.c: In function 'sqlite3NameFromToken':
build.c:509: warning: pointer targets in passing argument 1 of
'sqlite3StrNDup' differ in signedness
build.c: In function 'identPut':
build.c:1173: warning: pointer targets in passing argument 1 of
'sqlite3KeywordCode' differ in signedness
build.c: In function 'sqlite3CreateIndex':
build.c:2160: warning: pointer targets in assignment differ in signedness
build.c:2161: warning: pointer targets in passing argument 1 of
'strlen' differ in signedness
build.c: In function 'sqlite3Reindex':
build.c:2913: warning: pointer targets in passing argument 3 of
'sqlite3FindCollSeq' differ in signedness
date.c: In function 'isDate':
date.c:642: warning: pointer targets in passing argument 1 of
'parseDateOrTime' differ in signedness
date.c:645: warning: pointer targets in passing argument 1 of
'parseModifier' differ in signedness
date.c: In function 'strftimeFunc':
date.c:758: warning: pointer targets in initialization differ in signedness
expr.c: In function 'sqlite3RegisterExpr':
expr.c:238: warning: pointer targets in passing argument 1 of 'atoi'
differ in signedness
expr.c: In function 'sqlite3ExprAssignVarNumber':
expr.c:330: warning: pointer targets in passing argument 1 of 'atoi'
differ in signedness
expr.c: In function 'sqlite3ExprDup':
expr.c:418: warning: pointer targets in passing argument 1 of
'sqlite3StrNDup' differ in signedness
expr.c:418: warning: pointer targets in assignment differ in signedness
expr.c: In function 'sqlite3TokenCopy':
expr.c:435: warning: pointer targets in passing argument 1 of
'sqlite3StrNDup' differ in signedness
expr.c:435: warning: pointer targets in assignment differ in signedness
expr.c: In function 'sqlite3ExprIsInteger':
expr.c:755: warning: pointer targets in passing argument 1 of
'sqlite3GetInt32' differ in signedness
expr.c: In function 'nameResolverStep':
expr.c:1154: warning: pointer targets in assignment differ in signedness
expr.c: In function 'sqlite3CodeSubselect':
expr.c:1401: warning: pointer targets in initialization differ in signedness
expr.c: In function 'sqlite3ExprCode':
expr.c:1477: warning: pointer targets in passing argument 2 of
'codeInteger' differ in signedness
expr.c:1485: warning: pointer targets in passing argument 5 of
'sqlite3VdbeOp3' differ in signedness
expr.c:1498: warning: pointer targets in assignment differ in signedness
expr.c:1510: warning: pointer targets in passing argument 3 of
'sqlite3VdbeChangeP3' differ in signedness

Re: [sqlite] uninstall help

[Christian Smith]

On Mon, 31 Oct 2005, Adi Spivak wrote:

>
>hello.
>i have sqlite 2.8.17 installed on my system (compiled manually not a distro
>package)
>i wish to remove it (uninstall) it complitlly from my system and install the
>3.2.7
>i need to make sure it is removed so i can make sure that the program i need
>to install that will use sqlite will be compiled using sqlite3 libraries.
>Thanks.


Well, SQLite 2.8.17 will be libsqlite, and SQLite 3.2.7 will be
libsqlite3. The two will co-exist, and you can't compile for one and run
on the other, they have different function prefixes. So, if you link with
-lsqlite3, you will be using 3.2.7 only.


>Adi Spivak
>
>--
>Oplag Internet Solutions. ( http://www.oplag.net )
>
>

-- 
/"\
\ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
 X   - AGAINST MS ATTACHMENTS
/ \

[sqlite] uninstall help

[Adi Spivak]

hello. 
i have sqlite 2.8.17 installed on my system (compiled manually not a distro 
package) 
i wish to remove it (uninstall) it complitlly from my system and install the 
3.2.7 
i need to make sure it is removed so i can make sure that the program i need 
to install that will use sqlite will be compiled using sqlite3 libraries. 
Thanks. 
Adi Spivak 

--
Oplag Internet Solutions. ( http://www.oplag.net )

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] SQLite as a Windows kernel tool

[Rob Lohman]

I have been silently reading the conversation, but I have
to reply on this latest message.

- Original Message - 
From: "Fred Williams" <[EMAIL PROTECTED]>

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.


This is unfair. As stated it will actually compile. There are
just warnings to indicate data loss might occur. Which we
all know happens if you convert int64 to a char for example
(Which has nothing todo with the fact that it is a Microsoft
compiler, or Mickeysoft as you call it).

The original poster is (imho) just looking for clarification
if these possible problem spots are working as they are
supposed to, on all platforms. Isn't this a good discussion
to have? To make sure the codebase is at the best quality
it can be? I thought we would all benefit from such a thing,
guess you don't agree.


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


This would mean the original poster has to know every
in and out of the SQLite code. Fixing something that seems
obvious might break something else. Since the original
question was about whether the mentioned warnings are
real I doubt the poster has the knowledge to fix it himself
and no if there are any consequences or not.


us all, and won't come off as such an irritating whiner.


This is just completely rude and uncalled for. If you don't
want to "waste your time" discussing a genuine concern,
then why bother replying at all?

Regards,

Rob Lohman

p.s. funny how you are using "Mickeysoft" Outlook

Re: [sqlite] SQLite as a Windows kernel tool

[Nuno Lucas]

On 10/31/05, Fred Williams <[EMAIL PROTECTED]> wrote:
> 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.

If you forget about "Mickeysoft's latest and greatest" and only
consider GNU C compiler will that make you change your mind?

gcc 3.3 and 3.4 compile without warnings, but 4.0 is a lot more picky
even without -Wall.

For people like me that always enable all warnings, it makes it a must
to compile sqlite as a library, because it's a nightmare to use it
"embebed".

I still love sqlite, it's just a feature request, nothing more, nothing less.

As an example, I downloaded the preprocessed code, removed tclsqlite.c, and:

[EMAIL PROTECTED]:~/src/sqlite$ gcc-4.0 *.c
alter.c: In function 'renameTableFunc':
alter.c:50: warning: pointer targets in initialization differ in signedness
alter.c:61: warning: pointer targets in assignment differ in signedness
alter.c:69: warning: pointer targets in passing argument 1 of
'sqlite3GetToken' differ in signedness
alter.c: In function 'renameTriggerFunc':
alter.c:99: warning: pointer targets in initialization differ in signedness
alter.c:111: warning: pointer targets in assignment differ in signedness
alter.c:119: warning: pointer targets in passing argument 1 of
'sqlite3GetToken' differ in signedness
alter.c: In function 'sqlite3AlterFinishAddColumn':
alter.c:445: warning: pointer targets in passing argument 1 of
'sqlite3StrNDup' differ in signedness
btree.c: In function 'unlockBtreeIfUnused':
btree.c:1537: warning: pointer targets in assignment differ in signedness
build.c: In function 'sqlite3NameFromToken':
build.c:509: warning: pointer targets in passing argument 1 of
'sqlite3StrNDup' differ in signedness
build.c: In function 'identPut':
build.c:1173: warning: pointer targets in passing argument 1 of
'sqlite3KeywordCode' differ in signedness
build.c: In function 'sqlite3CreateIndex':
build.c:2160: warning: pointer targets in assignment differ in signedness
build.c:2161: warning: pointer targets in passing argument 1 of
'strlen' differ in signedness
build.c: In function 'sqlite3Reindex':
build.c:2913: warning: pointer targets in passing argument 3 of
'sqlite3FindCollSeq' differ in signedness
date.c: In function 'isDate':
date.c:642: warning: pointer targets in passing argument 1 of
'parseDateOrTime' differ in signedness
date.c:645: warning: pointer targets in passing argument 1 of
'parseModifier' differ in signedness
date.c: In function 'strftimeFunc':
date.c:758: warning: pointer targets in initialization differ in signedness
expr.c: In function 'sqlite3RegisterExpr':
expr.c:238: warning: pointer targets in passing argument 1 of 'atoi'
differ in signedness
expr.c: In function 'sqlite3ExprAssignVarNumber':
expr.c:330: warning: pointer targets in passing argument 1 of 'atoi'
differ in signedness
expr.c: In function 'sqlite3ExprDup':
expr.c:418: warning: pointer targets in passing argument 1 of
'sqlite3StrNDup' differ in signedness
expr.c:418: warning: pointer targets in assignment differ in signedness
expr.c: In function 'sqlite3TokenCopy':
expr.c:435: warning: pointer targets in passing argument 1 of
'sqlite3StrNDup' differ in signedness
expr.c:435: warning: pointer targets in assignment differ in signedness
expr.c: In function 'sqlite3ExprIsInteger':
expr.c:755: warning: pointer targets in passing argument 1 of
'sqlite3GetInt32' differ in signedness
expr.c: In function 'nameResolverStep':
expr.c:1154: warning: pointer targets in assignment differ in signedness
expr.c: In function 'sqlite3CodeSubselect':
expr.c:1401: warning: pointer targets in initialization differ in signedness
expr.c: In function 'sqlite3ExprCode':
expr.c:1477: warning: pointer targets in passing argument 2 of
'codeInteger' differ in signedness
expr.c:1485: warning: pointer targets in passing argument 5 of
'sqlite3VdbeOp3' differ in signedness
expr.c:1498: warning: pointer targets in assignment differ in signedness
expr.c:1510: warning: pointer targets in passing argument 3 of
'sqlite3VdbeChangeP3' differ in signedness
expr.c:1632: warning: pointer targets in assignment differ in signedness
expr.c:1766: warning: pointer targets in passing argument 5 of
'sqlite3VdbeOp3' differ in signedness
expr.c: In function 'sqlite3ExprCompare':
expr.c:2059: warning: pointer targets in passing argument 1 of
'sqlite3StrNICmp' differ in signedness
expr.c:2059: warning: pointer targets in passing argument 2 of
'sqlite3StrNICmp' differ in signedness
expr.c: In function 'analyzeAggregate':
expr.c:2191: warning: pointer targets in passing argument 2 of
'sqlite3FindFunction' differ in signedness
func.c: In function 'lengthFunc':
func.c:104: warning: pointer targets in initialization differ in signedness
func.c: In function 'substrFunc':
func.c:155: warning: pointer targets in assignment 

Re: [sqlite] built-in functrion suggestion: size of blob

[Nuno Lucas]

On 10/28/05, Joe Wilson <[EMAIL PROTECTED]> wrote:
> --- Nuno Lucas <[EMAIL PROTECTED]> wrote:
> > On 10/25/05, Joe Wilson <[EMAIL PROTECTED]> wrote:
> > > The built-in Sqlite length() function works just fine on blobs:
> > >
> > >   sqlite> select length(X'00');
> > >   5
> > >
> > > Why do you think it doesn't?
> >
> > I remember a few months ago noticing it would count UTF-8 chars, not
> > bytes, so it would not return the right length for blobs in all cases
> > (a '\0' is a valid UTF-8 char, but try with the '(c)' [copyright] sign,
> > which is 2 bytes).
> >
> > I don't have the code in front of me, and can be just my memory, but I
> > don't see that behaviour changing or would break a lot of SQL during
> > normal text manipulation.
> >
> > Regards,
> > ~Nuno Lucas
>
> You are mistaken. Text and blobs are different.
> TEXT is of type "SQLITE_TEXT". BLOB is of type "SQLITE_BLOB".
> length() has always correctly returned the size of a blob - look at the code:
>

[EMAIL PROTECTED]:~/src/sqlite$ sqlite3 test.db3
SQLite version 3.2.1
Enter ".help" for instructions
sqlite> create table x ( a TEXT, b BLOB );
sqlite> insert into x values ( 'Não', 'Não' );
sqlite> select * from x;
Não|Não
sqlite> select length(a), length(b) from x;
3|3
sqlite> .q
[EMAIL PROTECTED]:~/src/sqlite$ hexdump -c test.db3
000   S   Q   L   i   t   e   f   o   r   m   a   t   3  \0
010 004  \0 001 001  \0   @  \0  \0  \0 002  \0  \0  \0  \0
020  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0 001  \0  \0  \0 001
030  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0 001  \0  \0  \0  \0
040  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
060  \0  \0  \0  \0  \r  \0  \0  \0 001 003 317  \0 003 317  \0  \0
070  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
3c0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0   /
3d0 001 006 027 017 017 001   O   t   a   b   l   e   x   x 002   C
3e0   R   E   A   T   E   T   A   B   L   E   x   (
3f0   a   T   E   X   T   ,   b   B   L   O   B   )
400  \r  \0  \0  \0 001 003 363  \0 003 363  \0  \0  \0  \0  \0  \0
410  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
7f0  \0  \0  \0  \v 001 003 025 025   N 303 243   o   N 303 243   o
800

As you see from the hexdump, "Não" is encoded as UTF-8.

It's true it works if you insert a literal BLOB, like with
x'00112233', but it only means sqlite lacks a byte counting function
for the general case.

I don't complain about it, as I only use the SQLite C API, but it
means there is no coherency if different programs are used to
manipulate the database (that could insert the data in different
ways).

Also note that I've seen a lot of sqlite wrappers/managers in the past
that don't care the encoding used (still many people think they can
live with only the first 127 ASCII chars), inserting Latin-1 or others
literally, making the length function returning the wrong value when
accented chars or other symbols - like the (c) symbol - are found. It
would be nice if we could make a quick sanity check on the DB by
comparing the byte count against the string length.

For me, it's just a low priority feature request, but I believe there
are others who may think otherwise.


Regards,
~Nuno Lucas


> /*
> ** Implementation of the length() function
> */
> static void lengthFunc(
>   sqlite3_context *context,
>   int argc,
>   sqlite3_value **argv
> ){
>   int len;
>
>   assert( argc==1 );
>   switch( sqlite3_value_type(argv[0]) ){
> case SQLITE_BLOB:
> case SQLITE_INTEGER:
> case SQLITE_FLOAT: {
>   sqlite3_result_int(context, sqlite3_value_bytes(argv[0]));
>   break;
> }
> case SQLITE_TEXT: {
>   const char *z = sqlite3_value_text(argv[0]);
>   for(len=0; *z; z++){ if( (0xc0&*z)!=0x80 ) len++; }
>   sqlite3_result_int(context, len);
>   break;
> }
> default: {
>   sqlite3_result_null(context);
>   break;
> }
>   }
> }