[sqlite] in-code documentation for Mem->type

[Bernhard Döbler]

Hello,

vcdbeInt.h reads:

** Each value has a manifest type. The manifest type of the value stored
** in a Mem struct is returned by the MemType(Mem*) macro. The type is
** one of SQLITE_NULL, SQLITE_INTEGER, SQLITE_REAL, SQLITE_TEXT or
** SQLITE_BLOB.
*/
struct Mem {
  i64 i;  /* Integer value */
  int n;  /* Number of characters in string value, including
'\0' */
  u16 flags;  /* Some combination of MEM_Null, MEM_Str, MEM_Dyn,
etc. */
  u8  type;   /* One of MEM_Null, MEM_Str, etc. */

In the block comment SQLITE_REAL must obviously be SQLITE_FLOAT
In the inline-comment for the "type" member it must not be MEM_Null and the
like since MEM_Null != SQLITE_NULL
According to my understanding the MEM_* constants are used for the
"flags"-member indicating which members (string, float, integer) are validly
set.

Happy easter to all readers,
Bernhard

Re: [sqlite] Mem-Structure

[Bernhard Döbler]

Hello again,

your answer in fact means that - although I specify my string is zero
terminated - the n-Member of the Mem-structure is indispensable when
inserting data to the DB?

Bernhard

- Original Message - 
From: "D. Richard Hipp" <[EMAIL PROTECTED]>
To: "Bernhard DÃbler" <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, February 28, 2005 10:03 PM
Subject: Re: [sqlite] Mem-Structure


On Mon, 2005-02-28 at 20:03 +0100, Bernhard DÃbler wrote:
>
> vdbemem.c (2004 May 26) reads at about line 650:
>
>   if( pMem->enc==SQLITE_UTF8 && (flags & MEM_Term) ){
> assert( strlen(pMem->z)<=pMem->n );
> assert( pMem->z[pMem->n]==0 );
>   }
>

Strictly speaking, assert() is never needed.  These two asserts
were probably put in at different times.  The second assert is
the more restrictive of the two.  If either were eliminated it
would be the first.

[sqlite] Mem-Structure

[Bernhard Döbler]

Hello,

vdbemem.c (2004 May 26) reads at about line 650:

  if( pMem->enc==SQLITE_UTF8 && (flags & MEM_Term) ){
assert( strlen(pMem->z)<=pMem->n );
assert( pMem->z[pMem->n]==0 );
  }

First is tested if the length of the passed string is shorter or equal to
the passed number of bytes it's maximal allowed to be long. Secondly is
tested if the n-th byte of the string is a NULL-char

I don't recognize the actual need of the second assert.
if strlen(pMem->z) equals pMem->n then pMem->z[pMem->n] is of course equals
NULL
if strlen(pMem->z) was smaller than pMem->n then pMem->z[pMem->n] is  not 0
but there obviously must be a NULL char which instructs strlen to stop
counting characters.

The comment to the code reads, the check is done because of possible
erroneus databases.
I wonder what exactly is written into the database.
Are n bytes from pMem->z on written to the db? Is n written to the db too?
Is the actual length of the string at time of insertion written to the db?

Best,
Bernhard

Re: [sqlite] Version 3.1.3 is a headache

[Bernhard Döbler]

Isn't ID the field INNER JOIN uses to combine the tables...
That means you have to columns named ID but theire content is the same.

Bernhard

- Original Message - 
From: "Jakub Adamek" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, February 26, 2005 10:43 PM
Subject: [sqlite] Version 3.1.3 is a headache


> Hi, I really love SQLite, but upgrading to 3.1.3 was not a good idea. I 
> have already posted 3 tickets with rather serious problems with column 
> names.
> 
> The last one is really annoying and I can't believe the auto-tests could 
> have missed it ...
> 
>create table a (id, x);
>create table b (id, y);
>insert into a values (1,1);
>insert into b values (1,2);
>select * from a inner join b;
> 
>  column names returned: id,x,id,y How am I supposed to use such 
> column names? Ouwey. No wonder that my C++ wrapper does not want to work 
> with such a result set.
>