sqlite3_column_* with error handling

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

sqlite3_column_* with error handling

Brian Vincent
Hi, I'm currently writing a Go sqlite package, go-sqlite-lite.  I think it
provides a good "pure" SQLite experience with Go.

If I want to make sure that the sqlite3_column_* functions never provide a
false answer due to an error condition, like a memolry allocation error,
how should I go about that?  The documentation seems inconsistent here.

The documentation about sqlite3_column_*:

> If a memory allocation error occurs during the evaluation of any of these
routines, a default value is returned. The default value is either the
integer 0, the floating point number 0.0, or a NULL pointer. Subsequent
calls to sqlite3_errcode() will return SQLITE_NOMEM.

The documentation about sqlite3_errcode():

> If the most recent sqlite3_* API call associated with database connection
D failed, then the sqlite3_errcode(D) interface returns the numeric result
code or extended result code for that API call. If the most recent API call
was successful, then the return value from sqlite3_errcode() is undefined.
The sqlite3_extended_errcode() interface is the same except that it always
returns the extended result code even when extended result codes are
disabled.

1.  How can I check the error code if I'm unsure if the column function was
successful or not?  If it was successful, then the error code is undefined.
2.  Is SQLITE_NOMEM the only error code possible for the sqlite3_column_*
functions?
3.  Is it possible for every single one of the sqlite3_column_* functions
to fail in this manner?

Thanks,
Brian Vincent
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite3_column_* with error handling

Simon Slavin-3
Your question has been asked earlier this year, and no solution was posted.  I'm interested to find out whether things have improved.  To summarise the earlier post:

1) sqlite3_column_int() returns the value stored in that column, or 0 if an error occurred.

<https://sqlite.org/c3ref/column_blob.html> (last para)

2) If the value returned is 0, there's no way to tell whether it's because of an error or 0 really is the value returned in that column.

3) Presumably you're meant to call sqlite3_errcode() to find out which it is.

4) However, if the most recent API call was successful, then the return value from sqlite3_errcode() is undefined.  It could be an error code.  It could be 0.

<https://sqlite.org/c3ref/errcode.html> (first para)

5) Similar problems occur with some other sqlite3_column_*() functions.

6) As a result, the programmer cannot perform error-checking for these functions.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite3_column_* with error handling

Keith Medcalf

Well, that is not exactly true.  If you attempt to retrieve the column values properly, either no errors can occur or if they do, they are obvious.

1)  Query the column_type
2)  If the column_type is SQLITE_NULL then return a NULL indicator and stop processing these steps.
3)  If the column_type is SQLITE_INTEGER
    a)  Retrieve the column value using the column_int64 function, return that result and stop processing these steps.
4)  If the column_type is SQLITE_FLOAT
    a)  Retrieve the column value using the column_double function, return that result and stop processing these steps.
5)  If the column type is SQLITE_TEXT
    a)  Retrieve the column value data pointer using the column_text or column_text16
    b)  If the returned pointer is NULL, then an error has occurred and you can use the errcode() function to find out what it was.
    c)  If and only if the returned pointer is not null then you can use the corresponding column_bytes or column_bytes16 to get the length of the data.
    d)  Return the resulting pointer and length (or copy it, or whatever) and stop processing these steps.
6)  If the column type is SQLITE_BLOB
    a)  Retrieve the column value pointer using column_blob
    b)  If the returned pointer is NULL, then an error has occurred and you can use the errcode() function to find out what it was.
    c)  If and only if the returned pointer is not null then you can use column_bytes to get the length of the data.
    d)  Return the resulting pointer and length (or copy it, or whatever and stop processing these steps.

The only time it is possible for an error to occur is if *YOU* are requesting *DATA CONVERSION*, usually to or between byte-sequence (text) formats.  This is easy for you to detect because:

     If the column_type is not SQLITE_NULL and the output pointer of the function IS NULL, then an error has occurred.
     Otherwise, no error has occurred.


---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.

>-----Original Message-----
>From: sqlite-users [mailto:sqlite-users-
>[hidden email]] On Behalf Of Simon Slavin
>Sent: Tuesday, 4 September, 2018 12:03
>To: SQLite mailing list
>Subject: Re: [sqlite] sqlite3_column_* with error handling
>
>Your question has been asked earlier this year, and no solution was
>posted.  I'm interested to find out whether things have improved.  To
>summarise the earlier post:
>
>1) sqlite3_column_int() returns the value stored in that column, or 0
>if an error occurred.
>
><https://sqlite.org/c3ref/column_blob.html> (last para)
>
>2) If the value returned is 0, there's no way to tell whether it's
>because of an error or 0 really is the value returned in that column.
>
>3) Presumably you're meant to call sqlite3_errcode() to find out
>which it is.
>
>4) However, if the most recent API call was successful, then the
>return value from sqlite3_errcode() is undefined.  It could be an
>error code.  It could be 0.
>
><https://sqlite.org/c3ref/errcode.html> (first para)
>
>5) Similar problems occur with some other sqlite3_column_*()
>functions.
>
>6) As a result, the programmer cannot perform error-checking for
>these functions.
>
>Simon.
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite3_column_* with error handling

Clemens Ladisch
Keith Medcalf wrote:
> 6)  If the column type is SQLITE_BLOB
>     a)  Retrieve the column value pointer using column_blob
>     b)  If the returned pointer is NULL, then an error has occurred

"The return value from sqlite3_column_blob() for a zero-length BLOB is a NULL pointer."


Regards,
Clemens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite3_column_* with error handling

Keith Medcalf

On Tuesday, 4 September, 2018 14:00, Clemens Ladisch <[hidden email]> wrote:

>Keith Medcalf wrote:
>> 6)  If the column type is SQLITE_BLOB
>>     a)  Retrieve the column value pointer using column_blob
>>     b)  If the returned pointer is NULL, then an error has occurred

>"The return value from sqlite3_column_blob() for a zero-length BLOB
>is a NULL pointer."

Hmmm.  Yes.  

" The values returned by sqlite3_column_bytes() and sqlite3_column_bytes16() do not include the zero terminators at the end of the string. For clarity: the values returned by sqlite3_column_bytes() and sqlite3_column_bytes16() are the number of bytes in the string, not the number of characters.

Strings returned by sqlite3_column_text() and sqlite3_column_text16(), even empty strings, are always zero-terminated. The return value from sqlite3_column_blob() for a zero-length BLOB is a NULL pointer. "

So, an empty string returns a valid pointer but the bytes count is zero.  

For an empty blob, the returned pointer is NULL and the bytes count is zero.  So, for column_text the test for a NULL pointer will indicate an error.  

In the case of a BLOB if a NULL pointer is returned the error code must be retrieved and then if and only if the bytes counter is greater than 0 is the error valid.

Does this mean that if you are retrieving the value of a blob via the colmn_blob interface you should ask for the column_bytes first and only expect a NULL pointer if the bytes count is zero?

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.






_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite3_column_* with error handling

J Decker
On Tue, Sep 4, 2018 at 2:11 PM Keith Medcalf <[hidden email]> wrote:

>
> On Tuesday, 4 September, 2018 14:00, Clemens Ladisch <[hidden email]>
> wrote:
>
> >Keith Medcalf wrote:
> >> 6)  If the column type is SQLITE_BLOB
> >>     a)  Retrieve the column value pointer using column_blob
> >>     b)  If the returned pointer is NULL, then an error has occurred
>
> >"The return value from sqlite3_column_blob() for a zero-length BLOB
> >is a NULL pointer."
>
> Hmmm.  Yes.
>
> " The values returned by sqlite3_column_bytes() and
> sqlite3_column_bytes16() do not include the zero terminators at the end of
> the string. For clarity: the values returned by sqlite3_column_bytes() and
> sqlite3_column_bytes16() are the number of bytes in the string, not the
> number of characters.
>

(for text)
column_bytes() returns the number of bytes specified for the string, and
has nothing to do with NUL unless you end up with a tranlsation from utf8
to utf16 or vice versa.  So it can/will return the number of bytes
including nulls in the text.


>
> Strings returned by sqlite3_column_text() and sqlite3_column_text16(),
> even empty strings, are always zero-terminated. The return value from
> sqlite3_column_blob() for a zero-length BLOB is a NULL pointer. "
>
if there is no transform between utf16 or utf8, text returns a pointer
which may contain nuls; I do forget, but it may be the buffer is always
allocated +1 and include an extra nul... (probably does)
Such nuls can be isnerted with the escape '||char(0)||'


>
> So, an empty string returns a valid pointer but the bytes count is zero.
>
> For an empty blob, the returned pointer is NULL and the bytes count is
> zero.  So, for column_text the test for a NULL pointer will indicate an
> error.
>
> In the case of a BLOB if a NULL pointer is returned the error code must be
> retrieved and then if and only if the bytes counter is greater than 0 is
> the error valid.
>
> Does this mean that if you are retrieving the value of a blob via the
> colmn_blob interface you should ask for the column_bytes first and only
> expect a NULL pointer if the bytes count is zero?
>
> ---
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>
>
>
>
>
>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite3_column_* with error handling

Clemens Ladisch
In reply to this post by Keith Medcalf
Keith Medcalf wrote:
> In the case of a BLOB if a NULL pointer is returned the error code must
> be retrieved and then if and only if the bytes counter is greater than
> 0 is the error valid.
>
> Does this mean that if you are retrieving the value of a blob via the
> colmn_blob interface you should ask for the column_bytes first and only
> expect a NULL pointer if the bytes count is zero?

For detecting errors, it does not really matter whether you call _blob
or _bytes first.  (A zeroblob might need to be expanded in the _blob
call, but it does not matter when exactly this error happens.)

In many cases, your code will copy the value elsewhere, so it will be
necessary to call _bytes first to allocate the buffer.

If you do not check the type beforehand, _blob must be called first
because the possible type conversion might change the size.


Regards,
Clemens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite3_column_* with error handling

Richard Hipp-3
In reply to this post by Brian Vincent
On 9/4/18, Brian Vincent <[hidden email]> wrote:

> Hi, I'm currently writing a Go sqlite package, go-sqlite-lite.  I think it
> provides a good "pure" SQLite experience with Go.
>
> If I want to make sure that the sqlite3_column_* functions never provide a
> false answer due to an error condition, like a memolry allocation error,
> how should I go about that?  The documentation seems inconsistent here.
>
> The documentation about sqlite3_column_*:
>
>> If a memory allocation error occurs during the evaluation of any of these
> routines, a default value is returned. The default value is either the
> integer 0, the floating point number 0.0, or a NULL pointer. Subsequent
> calls to sqlite3_errcode() will return SQLITE_NOMEM.
>
> The documentation about sqlite3_errcode():
>
>> If the most recent sqlite3_* API call associated with database connection
> D failed, then the sqlite3_errcode(D) interface returns the numeric result
> code or extended result code for that API call. If the most recent API call
> was successful, then the return value from sqlite3_errcode() is undefined.
> The sqlite3_extended_errcode() interface is the same except that it always
> returns the extended result code even when extended result codes are
> disabled.
>
> 1.  How can I check the error code if I'm unsure if the column function was
> successful or not?  If it was successful, then the error code is undefined.

Just call sqlite3_errcode().  It will return SQLITE_OK if the
sqlite3_column function was successful.  If sqlite3_errorcode()
returns something other than SQLITE_OK, then some recent API failed.
It might not have been the sqlite3_column function, but it is still a
failures, so just go with it.

> 2.  Is SQLITE_NOMEM the only error code possible for the sqlite3_column_*
> functions?

SQLITE_RANGE if you provide an invalid column number.  SQLITE_MISUSE
if the prepared statement has been reset or finalized. That is all in
the current implementation, but new error codes might be added in the
future.

> 3.  Is it possible for every single one of the sqlite3_column_* functions
> to fail in this manner?

I think only the routines that returns TEXT and BLOB use malloc() in
the current implementation.  That might change in the future though.


--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite3_column_* with error handling

Simon Slavin-3
On 5 Sep 2018, at 11:22am, Richard Hipp <[hidden email]> wrote:

> Just call sqlite3_errcode().  It will return SQLITE_OK if the
> sqlite3_column function was successful.

In respect of the above, I observe the second sentence of

<https://sqlite.org/c3ref/errcode.html>

If the most recent API call was successful, then the return value from sqlite3_errcode() is undefined."

It's possible that the documentation needs to be corrected.  Or perhaps this is a special case not mentioned in the documentation.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite3_column_* with error handling

Brian Vincent
In reply to this post by Richard Hipp-3
On Wed, Sep 5, 2018 at 5:22 AM Richard Hipp <[hidden email]> wrote:

> On 9/4/18, Brian Vincent <[hidden email]> wrote:
> > Hi, I'm currently writing a Go sqlite package, go-sqlite-lite.  I think
> it
> > provides a good "pure" SQLite experience with Go.
> >
> > If I want to make sure that the sqlite3_column_* functions never provide
> a
> > false answer due to an error condition, like a memolry allocation error,
> > how should I go about that?  The documentation seems inconsistent here.
> >
> > The documentation about sqlite3_column_*:
> >
> >> If a memory allocation error occurs during the evaluation of any of
> these
> > routines, a default value is returned. The default value is either the
> > integer 0, the floating point number 0.0, or a NULL pointer. Subsequent
> > calls to sqlite3_errcode() will return SQLITE_NOMEM.
> >
> > The documentation about sqlite3_errcode():
> >
> >> If the most recent sqlite3_* API call associated with database
> connection
> > D failed, then the sqlite3_errcode(D) interface returns the numeric
> result
> > code or extended result code for that API call. If the most recent API
> call
> > was successful, then the return value from sqlite3_errcode() is
> undefined.
> > The sqlite3_extended_errcode() interface is the same except that it
> always
> > returns the extended result code even when extended result codes are
> > disabled.
> >
> > 1.  How can I check the error code if I'm unsure if the column function
> was
> > successful or not?  If it was successful, then the error code is
> undefined.
>
> Just call sqlite3_errcode().  It will return SQLITE_OK if the
> sqlite3_column function was successful.  If sqlite3_errorcode()
> returns something other than SQLITE_OK, then some recent API failed.
> It might not have been the sqlite3_column function, but it is still a
> failures, so just go with it.
>

From my testing, it appears that this information isn't exactly correct.
In my tests, when I call sqlite3_column_int64 for example, and it's
successful, sqlite_errcode() immediately afterwards is returning
SQLITE_ROW, which leads me to believe that it's not setting the error code
to SQLITE_OK when it's successful.  If I can't trust sqlite_errcode() when
it's successful, how can I be sure that it succeeded?

>
> > 2.  Is SQLITE_NOMEM the only error code possible for the sqlite3_column_*
> > functions?
>
> SQLITE_RANGE if you provide an invalid column number.  SQLITE_MISUSE
> if the prepared statement has been reset or finalized. That is all in
> the current implementation, but new error codes might be added in the
> future.
>
> > 3.  Is it possible for every single one of the sqlite3_column_* functions
> > to fail in this manner?
>
> I think only the routines that returns TEXT and BLOB use malloc() in
> the current implementation.  That might change in the future though.
>
>
> --
> D. Richard Hipp
> [hidden email]
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite3_column_* with error handling

Simon Slavin-3
On 13 Sep 2018, at 3:49pm, Brian Vincent <[hidden email]> wrote:

> From my testing, it appears that this information isn't exactly correct.
> In my tests, when I call sqlite3_column_int64 for example, and it's
> successful, sqlite_errcode() immediately afterwards is returning
> SQLITE_ROW, which leads me to believe that it's not setting the error code
> to SQLITE_OK when it's successful.  If I can't trust sqlite_errcode() when
> it's successful, how can I be sure that it succeeded?

You are correct.  The documentation is correct.  The post you are reading is incorrect.

The documentation for sqlite_errcode() states clearly that if the previous operation was successful, the value returned by sqlite_errcode() is undefined.  In other words, the only time you can use sqlite_errcode() with confidence is when an API call has just returned an error code.

However sqlite3_column_int64() can return 0 for two reasons: the value it's returning is genuinely 0, or an error occurred during its execution.  If it does return 0 then sqlite_errcode() alone is not sufficient to determine which of these happened.

I believe that your concern is valid and should be addressed.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite3_column_* with error handling

Brian Vincent
In reply to this post by Keith Medcalf
On Tue, Sep 4, 2018 at 1:31 PM Keith Medcalf <[hidden email]> wrote:

>
> Well, that is not exactly true.  If you attempt to retrieve the column
> values properly, either no errors can occur or if they do, they are obvious.
>
> 1)  Query the column_type
> 2)  If the column_type is SQLITE_NULL then return a NULL indicator and
> stop processing these steps.
> 3)  If the column_type is SQLITE_INTEGER
>     a)  Retrieve the column value using the column_int64 function, return
> that result and stop processing these steps.
> 4)  If the column_type is SQLITE_FLOAT
>     a)  Retrieve the column value using the column_double function, return
> that result and stop processing these steps.
> 5)  If the column type is SQLITE_TEXT
>     a)  Retrieve the column value data pointer using the column_text or
> column_text16
>     b)  If the returned pointer is NULL, then an error has occurred and
> you can use the errcode() function to find out what it was.
>     c)  If and only if the returned pointer is not null then you can use
> the corresponding column_bytes or column_bytes16 to get the length of the
> data.
>     d)  Return the resulting pointer and length (or copy it, or whatever)
> and stop processing these steps.
> 6)  If the column type is SQLITE_BLOB
>     a)  Retrieve the column value pointer using column_blob
>     b)  If the returned pointer is NULL, then an error has occurred and
> you can use the errcode() function to find out what it was.
>     c)  If and only if the returned pointer is not null then you can use
> column_bytes to get the length of the data.
>     d)  Return the resulting pointer and length (or copy it, or whatever
> and stop processing these steps.
>
> The only time it is possible for an error to occur is if *YOU* are
> requesting *DATA CONVERSION*, usually to or between byte-sequence (text)
> formats.  This is easy for you to detect because:
>
>      If the column_type is not SQLITE_NULL and the output pointer of the
> function IS NULL, then an error has occurred.
>      Otherwise, no error has occurred.
>
>
Thanks for this reply.  I think this is my answer.  Dr Hipp suggested that
sqlite_errcode would return SQLITE_OK after a column function succeeds,
otherwise it would return other errors such as SQLITE_RANGE or
SQLITE_MISUSE.  But, it doesn't appear to be the case that the error code
is set to SQLITE_OK on success.

So it seems that the only way to differentiate an error case from a NULL
value is to check the column type beforehand as you suggested.

It also seems that the only way to detect that the column number is out of
range is for me to check the ColumnCount beforehand and do the checking
myself.

To be honest this API seems a little goofy and I would love to see column
functions that have the ability to return an error.  But I can work with
this API, as long as I have a guarantee that the error code is set when the
column type is not SQLITE_NULL and sqlite3_column_text and
sqlite3_column_blob return a null pointer.

Dr. Hipp (and the documentation) say that SQLite reserves the right to
possibly use malloc in the future for sqlite3_column_int, int64, double,
and possibly fail with SQLITE_NOMEM.  But I don't see how I could ever know
if it's correct to check sqlite3_errcode, so I don't see how this is
possible.  I also need a guarantee that these functions cannot fail (after
I've checked the column count and column type).

These guarantees are not very clear in the documentation.

Thanks for your help.

>
> ---
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>
> >-----Original Message-----
> >From: sqlite-users [mailto:sqlite-users-
> >[hidden email]] On Behalf Of Simon Slavin
> >Sent: Tuesday, 4 September, 2018 12:03
> >To: SQLite mailing list
> >Subject: Re: [sqlite] sqlite3_column_* with error handling
> >
> >Your question has been asked earlier this year, and no solution was
> >posted.  I'm interested to find out whether things have improved.  To
> >summarise the earlier post:
> >
> >1) sqlite3_column_int() returns the value stored in that column, or 0
> >if an error occurred.
> >
> ><https://sqlite.org/c3ref/column_blob.html> (last para)
> >
> >2) If the value returned is 0, there's no way to tell whether it's
> >because of an error or 0 really is the value returned in that column.
> >
> >3) Presumably you're meant to call sqlite3_errcode() to find out
> >which it is.
> >
> >4) However, if the most recent API call was successful, then the
> >return value from sqlite3_errcode() is undefined.  It could be an
> >error code.  It could be 0.
> >
> ><https://sqlite.org/c3ref/errcode.html> (first para)
> >
> >5) Similar problems occur with some other sqlite3_column_*()
> >functions.
> >
> >6) As a result, the programmer cannot perform error-checking for
> >these functions.
> >
> >Simon.
> >_______________________________________________
> >sqlite-users mailing list
> >[hidden email]
> >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite3_column_* with error handling

Brian Vincent
In reply to this post by Keith Medcalf
On Tue, Sep 4, 2018 at 4:11 PM Keith Medcalf <[hidden email]> wrote:

>
> On Tuesday, 4 September, 2018 14:00, Clemens Ladisch <[hidden email]>
> wrote:
>
> >Keith Medcalf wrote:
> >> 6)  If the column type is SQLITE_BLOB
> >>     a)  Retrieve the column value pointer using column_blob
> >>     b)  If the returned pointer is NULL, then an error has occurred
>
> >"The return value from sqlite3_column_blob() for a zero-length BLOB
> >is a NULL pointer."
>
> Hmmm.  Yes.
>
> " The values returned by sqlite3_column_bytes() and
> sqlite3_column_bytes16() do not include the zero terminators at the end of
> the string. For clarity: the values returned by sqlite3_column_bytes() and
> sqlite3_column_bytes16() are the number of bytes in the string, not the
> number of characters.
>
> Strings returned by sqlite3_column_text() and sqlite3_column_text16(),
> even empty strings, are always zero-terminated. The return value from
> sqlite3_column_blob() for a zero-length BLOB is a NULL pointer. "
>
> So, an empty string returns a valid pointer but the bytes count is zero.
>
> For an empty blob, the returned pointer is NULL and the bytes count is
> zero.  So, for column_text the test for a NULL pointer will indicate an
> error.
>
> In the case of a BLOB if a NULL pointer is returned the error code must be
> retrieved and then if and only if the bytes counter is greater than 0 is
> the error valid.
>
> Does this mean that if you are retrieving the value of a blob via the
> colmn_blob interface you should ask for the column_bytes first and only
> expect a NULL pointer if the bytes count is zero?
>
> This is a great question.  My only guess is that you should always check
the byte count first, and if it's zero, you shouldn't even request the
blob.  Is that the answer?


> ---
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>
>
>
>
>
>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users