libdbi-users — General libdbi discussion and support

Re: [libdbi-users] dbi_result_get_ulonglong overflow

[Markus H. <mar...@mh...>]

Devin Reade writes:
 > I'm going to have to take a step back for a moment:  Currently the only
 > thing that I have that is using libdbi is one legacy application.  I'm
 > not saying that I won't use it in future projects, just that I have no
 > active projects at the moment depending on it.  Therefore other users
 > may have more of an opinion.  (I originally stepped into this conversation
 > to answer the "what's wrong with ato*?" question on a more theoretical
 > basis.)
 > 

I'm sorry about that, I've left you in the To: field unintentionally -
I wanted to solicit some opinions from the list instead. But thanks
anyway for providing your thoughts on this matter.

regards,
Markus

 > Also, your userbase may be wary of anything that results
 > in an API change, at least between minor versions.  Even if you can't
 > propagate an error, you should be able to log the problem, though.
 > 
 > That being said, I do not think that it is unreasonable for dbd_fetch_row
 > to error out if there is a problem parsing any of the result columns.
 > One should be able to determine (from log files, if not programatically)
 > the set of all problems in that case, though.
 > 
 > Devin
 > -- 
 > 	I'm not a complete idiot, some parts are missing. 
 > 
 > 
 > ------------------------------------------------------------------------------
 > This SF.Net email is sponsored by the Verizon Developer Community
 > Take advantage of Verizon's best-in-class app development support
 > A streamlined, 14 day to market process makes app distribution fast and easy
 > Join now and get one step closer to millions of Verizon customers
 > http://p.sf.net/sfu/verizon-dev2dev 
 > _______________________________________________
 > libdbi-users mailing list
 > lib...@li...
 > https://lists.sourceforge.net/lists/listinfo/libdbi-users

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-users] dbi_result_get_ulonglong overflow

[Devin R. <gd...@gn...>]

Markus Hoenicka <mar...@mh...> wrote:

> I've had a look at libdbi-driver's current ato*() usage. As far as I
> can see it is used only to turn raw row data into integers by
> functions which do not return values, i.e. without an easy way to
> indicate conversion errors. I haven't checked all drivers yet, but I
> see two options:
[snip]

I'm going to have to take a step back for a moment:  Currently the only
thing that I have that is using libdbi is one legacy application.  I'm
not saying that I won't use it in future projects, just that I have no
active projects at the moment depending on it.  Therefore other users
may have more of an opinion.  (I originally stepped into this conversation
to answer the "what's wrong with ato*?" question on a more theoretical
basis.)

Also, your userbase may be wary of anything that results
in an API change, at least between minor versions.  Even if you can't
propagate an error, you should be able to log the problem, though.

That being said, I do not think that it is unreasonable for dbd_fetch_row
to error out if there is a problem parsing any of the result columns.
One should be able to determine (from log files, if not programatically)
the set of all problems in that case, though.

Devin
-- 
	I'm not a complete idiot, some parts are missing. 

Re: [libdbi-users] dbi_result_get_ulonglong overflow

[Markus H. <mar...@mh...>]

Devin Reade writes:
 > In the particular case of this use in libdbi, I've not looked at the
 > code to see to what extent it is an *actual* problem; however as a
 > generalization, I would advise against using ato*() functions and instead
 > use strto*() functions because the latter provides input error checks
 > that the former does not.

I've had a look at libdbi-driver's current ato*() usage. As far as I
can see it is used only to turn raw row data into integers by
functions which do not return values, i.e. without an easy way to
indicate conversion errors. I haven't checked all drivers yet, but I
see two options:

1) make the functions in question return error codes. This would allow
dbd_fetch_row() to return an error code as well. However, an error in
a single field would make the operation fail.

2) use a field flag to tag the affected field only. This would require
users to check integer fields manually, in a similar fashion as you
have to check for NULL values if this is relevant.

What do you think?

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-users] dbi_result_get_ulonglong overflow

[Markus H. <mar...@mh...>]

Devin Reade writes:
 > They should at least be as portable as the ato* functions, unless
 > perhaps someone is still using a K&R C compiler somewhere, which
 > I doubt. If there's any portability issue, I would expect it to 
 > rear its head more for the 'long long' versions of both rather than
 > ato* vs strto*.
 > 

I've checked the repository. Obviously atoll() was missing from MinGW
(for the more or less native Windows port of libdbi). Does anyone
happen to know if MinGW still lacks atoll()/strtoll() support these
days?

In any case, we stole an atoll() implementation from MySQL back then,
which upon close inspection also turns out to be implemented via its
own strtoll(). Therefore switching from ato*() to strto*() should not
hurt.

 > That being said, the only real test is empirical.
 > 

True indeed. I'll look into this.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-users] dbi_result_get_ulonglong overflow

[Devin R. <gd...@gn...>]

Markus Hoenicka <mar...@mh...> wrote:

> What about the portability of the strto* functions?

They should at least be as portable as the ato* functions, unless
perhaps someone is still using a K&R C compiler somewhere, which
I doubt. If there's any portability issue, I would expect it to 
rear its head more for the 'long long' versions of both rather than
ato* vs strto*.

That being said, the only real test is empirical.

Devin
-- 
	You can't be truly paranoid unless you're sure they have
	already got you.				- Pavel Kankovsky

Re: [libdbi-users] dbi_result_get_ulonglong overflow

[Markus H. <mar...@mh...>]

Devin Reade writes:
 > The ato* are indeed often implemented in terms of strto*.  The problem
 > is that the ato* signature just doesn't lend itself to error
 > checks, so even if they wrap strto*, error information gets lost in
 > the wrapper layer.

What about the portability of the strto* functions? I recall we had to
add an implementation of atoll() to the libdbi sources to compile it
on at least one platform (I can't quite recall which one). Can we
expect that all platforms which are currently supported provide all
required strto*() functions?

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-users] dbi_result_get_ulonglong overflow

[Markus H. <mar...@mh...>]

Devin Reade <gd...@gn...> was heard to say:

> Markus Hoenicka <mar...@mh...> wrote:
>
>> To better deal with your shock: Could you please elaborate what's
>> wrong with atoll()?
>
> In the particular case of this use in libdbi, I've not looked at the
> code to see to what extent it is an *actual* problem; however as a
> generalization, I would advise against using ato*() functions and instead
> use strto*() functions because the latter provides input error checks
> that the former does not.  For example, if someone provides "073Ah" as
> input (thinking of the old DOS style hex stuff), what do they get?
>
> atol:   0x49 with no indication that the whole string wasn't parsed
> strtol: 0x3B, with an indication that the "Ah" wasn't parsed (assuming
>         a zero base) or 0x73a with an indication that 'h' wasn't parsed
>         (assuming a base of 16).
>
> In code inspections, ato*() is something my eye is drawn to as a
> potential source of problems, just as gotos are.  I don't remember if
> ato*() were mentioned in the classic paper
>   "Can't Happen or /*NOT REACHED*/ or Real Programs Drop Core"
> but if not they should have been.
>

Thanks for elaborating on this. I guess I have incorrectly generalized  
from FreeBSD that ato*() are wrappers around the corresponding  
strto*() functions. If they are indeed separately implemented in other  
OSes, you have a good point in avoiding ato*() functions in libdbi. A  
quick look at the code suggests indeed that there is insufficient  
error checking on the return of the string to number conversions.

regards,
Markus


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-users] dbi_result_get_ulonglong overflow

[Markus H. <mar...@mh...>]

Quoting Vikram Noel Ambrose <noe...@gm...>:

> I was pretty shocked to see an atoll call in libdbi. But there is no
> point on going on about that.
>

To better deal with your shock: Could you please elaborate what's  
wrong with atoll()? I recall from my home platform (FreeBSD) that  
atoll() is merely a wrapper around strtoll() anyways. So do you mind  
the use of atoll() per se or the lack of a potentially necessary  
discrimination between strtoll() and strtoull()?

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-users] dbi_result_get_ulonglong overflow

[Vikram N. A. <noe...@gm...>]

Vikram Noel Ambrose wrote:
> I can't seem to read back BIGINT UNSIGNED (8bytes) from a mysql database.
>
> For example:
> A value of     "10988581603938712255" = 0x987F48BFB028BABF
> is returned as  "9223372036854775807" = 0x7FFFFFFFFFFFFFFF
>
> Something somewhere is capping off my BIGINT UNSIGNED to the maximum 
> of a signed 8byte number.
>
> I'm using libdbi-0.8.3 on Ubuntu-9.10 X86_64.
>
>
> Vikram.
>
>
>
I think I may have found the cause of the problem:

Line:726 in dbd_mysql.c
data->d_longlong = (long long) atoll(raw); break;

I was pretty shocked to see an atoll call in libdbi. But there is no 
point on going on about that.

Just as a hack, I replaced it with, strtoull(raw,NULL,10);  and it seems 
to be working. Obviously this is not going to work with actual signed 
and negative numbers.

How do we fix this?


Vikram.

[libdbi-users] dbi_result_get_ulonglong overflow

[Vikram N. A. <noe...@gm...>]

I can't seem to read back BIGINT UNSIGNED (8bytes) from a mysql database.

For example:
A value of     "10988581603938712255" = 0x987F48BFB028BABF
is returned as  "9223372036854775807" = 0x7FFFFFFFFFFFFFFF

Something somewhere is capping off my BIGINT UNSIGNED to the maximum of 
a signed 8byte number.

I'm using libdbi-0.8.3 on Ubuntu-9.10 X86_64.


Vikram.

Re: [libdbi-users] Error -7 When retrieving NULL flag

[Markus H. <mar...@mh...>]

Vikram Noel Ambrose <noe...@gm...> uttered:

> Example query:
>
> SELECT id,ISNULL(data) FROM....
> or
> SELECT id,data IS NULL FROM....
> or
> SELECT id,CASE WHEN data IS NULL THEN 0 ELSE 1 END AS is_data_null FROM....
>
> dbi_result_get_int_idx(result,2);
>
> Gives me an error:
> -7: The requested variable type does not match what libdbi thinks it
> should be
>
> I'm pretty sure the last two queries are ANSI SQL.
>
> Any ideas how I can retrieve the result of those queries?

I think this is not a problem of the queries themselves. If they  
failed, you'd get a different error. It is just a matter of how the  
database engine returns your values. The libdbi error indicates that  
it obviously doesn't use INT as return type.

There are a couple of options to deal with this:

1) use dbi_result_get_field_type() or dbi_result_get_field_type_idx()  
to check the return type before retrieving the value. Different  
database engines may use different types.

2) use explicit return types like text as they might cause less  
problems, something along the lines of:

SELECT id,CASE WHEN data IS NULL THEN 'null' ELSE 'notnull' END AS  
is_data_null FROM...

3) use libdbi metadata functions to check for NULL values instead of  
using SQL. See dbi_result_field_is_null() and  
dbi_result_field_is_null_idx()

4) the upcoming libdbi release will provide XXX_as_string() and  
XXX_as_longlong() functions which attempt to cast the return values  
regardless of their original types. These might serve as last resorts  
as well as the casting is done in a driver-specific manner.

regards,
Markus



-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

[libdbi-users] Error -7 When retrieving NULL flag

[Vikram N. A. <noe...@gm...>]

Example query:

SELECT id,ISNULL(data) FROM....
or
SELECT id,data IS NULL FROM....
or
SELECT id,CASE WHEN data IS NULL THEN 0 ELSE 1 END AS is_data_null FROM....

dbi_result_get_int_idx(result,2);

Gives me an error:
-7: The requested variable type does not match what libdbi thinks it 
should be

I'm pretty sure the last two queries are ANSI SQL.

Any ideas how I can retrieve the result of those queries?



Vikram.

Re: [libdbi-users] out of memory

[Markus H. <mar...@mh...>]

Vikram Noel Ambrose writes:
 > The malloc inside _binary_copy_idx was failing. And I have no idea why. 
 > But a few system restarts and libdbi installations later, its started 
 > working. Must have had one too many segfaults that day. Poor computer.
 > 
 > Sorry for the false alarm.

Thanks for the all-clear.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-users] out of memory

[Vikram N. A. <noe...@gm...>]

Markus Hoenicka wrote:
> Hi Vik,
>
> Vikram Noel Ambrose <noe...@gm...> was heard to say:
>
>   
>> Ubuntu-9.10 x86_64, lidbi and mysql driver from the distro repos (0.8.3.1).
>>
>> I can insert a 40kb MEDIUMBLOB into a table with no problem, but when I,
>> dbi_conn_queryf, dbi_result_first_row and then
>> dbi_result_get_binary_copy_idx, I get an out of memory error.
>>
>> The blob seems to be consistent from an md5sum I took through the
>> mysqlclient.
>>     
>
> Could you provide a stripped-down testcase to reproduce this problem?  
> I'd like to see if it fails on 32bit systems as well.
>
>   
>> I tried to debug the problem, by downloading the libdbi/-driver sources
>> and peppering it a little. But I cannot run the compiled code on my
>> machine. I get a general protection fault from libdbi.so.0.1.0 when I
>> try to run my home built dbi.
>>
>>     
>
> Did you check the distro repo for any patches that they applied? They  
> might have fixed 64bit issues, if any. If they build from stock  
> sources, at least an unmodified homebuilt library should work ok.
>
> regards,
> Markus
>
>
>   
The malloc inside _binary_copy_idx was failing. And I have no idea why. 
But a few system restarts and libdbi installations later, its started 
working. Must have had one too many segfaults that day. Poor computer.

Sorry for the false alarm.

cheers,


Vik.

Re: [libdbi-users] out of memory

[Markus H. <mar...@mh...>]

Hi Vik,

Vikram Noel Ambrose <noe...@gm...> was heard to say:

> Ubuntu-9.10 x86_64, lidbi and mysql driver from the distro repos (0.8.3.1).
>
> I can insert a 40kb MEDIUMBLOB into a table with no problem, but when I,
> dbi_conn_queryf, dbi_result_first_row and then
> dbi_result_get_binary_copy_idx, I get an out of memory error.
>
> The blob seems to be consistent from an md5sum I took through the
> mysqlclient.

Could you provide a stripped-down testcase to reproduce this problem?  
I'd like to see if it fails on 32bit systems as well.

>
> I tried to debug the problem, by downloading the libdbi/-driver sources
> and peppering it a little. But I cannot run the compiled code on my
> machine. I get a general protection fault from libdbi.so.0.1.0 when I
> try to run my home built dbi.
>

Did you check the distro repo for any patches that they applied? They  
might have fixed 64bit issues, if any. If they build from stock  
sources, at least an unmodified homebuilt library should work ok.

regards,
Markus


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

[libdbi-users] out of memory

[Vikram N. A. <noe...@gm...>]

Ubuntu-9.10 x86_64, lidbi and mysql driver from the distro repos (0.8.3.1).

I can insert a 40kb MEDIUMBLOB into a table with no problem, but when I, 
dbi_conn_queryf, dbi_result_first_row and then 
dbi_result_get_binary_copy_idx, I get an out of memory error.

The blob seems to be consistent from an md5sum I took through the 
mysqlclient.

I tried to debug the problem, by downloading the libdbi/-driver sources 
and peppering it a little. But I cannot run the compiled code on my 
machine. I get a general protection fault from libdbi.so.0.1.0 when I 
try to run my home built dbi.

Whats going on?


Vik.

Re: [libdbi-users] UNIX Timestamp - DATE to UTC conversion

[Toby T. <to...@te...>]

On 19-Nov-08, at 8:42 AM, Ken Ramsay wrote:

>
> Thanks guys,
>
> MySQL defines the field as a DATETIME , so the return type is time_t.

No; you are using an expression, not the column, so the result type  
is indeed BIGINT, as Markus surmised (his explanation was correct, as  
far as I can determine).

> As
> far as I could find out, there is no helper funtion to convert this  
> into
> secs from 1 Jan 1970 ,

You indeed get seconds from UNIX epoch, as documented*, if you access  
the returned result field using 'dbi_result_get_longlong_idx()'.

(Or if you want to retrieve by name, I suggest using an alias for  
maintainability/readability's sake.)

--Toby

* - http://dev.mysql.com/doc/refman/5.0/en/date-and-time- 
functions.html#function_unix-timestamp


> so I got around it by using the difftime() call
> and subtracting the returned value from 1/1/1970. difftime()  
> returns the
> difference in seconds.
>
> Not sure it is the most elegant way to do it but it works ...;-}
>
> Cheers
>
>
>
> -----Original Message-----
> From: Markus Hoenicka [mailto:mar...@mh...]
> Sent: Tuesday, November 18, 2008 5:38 PM
> To: Ken Ramsay
> Cc: lib...@li...; rr...@ma...
> Subject: [libdbi-users] UNIX Timestamp - DATE to UTC conversion
>
> Ken Ramsay writes:
>>           time = dbi_result_get_uint(result,
>> "UNIX_TIMESTAMP(HIST_Timestamp)");
>
> Without actually trying the code: one rough guess is that MySQL  
> does not
> return the timestamp as an uint value but as something longer. Did you
> try using dbi_result_get_field_type() and
> dbi_result_get_field_attrib() to find out which type is returned?
>
> regards,
> Markus
>
> --
> Markus Hoenicka
> mar...@ca...
> (Spam-protected email: replace the quadrupeds with "mhoenicka")
> http://www.mhoenicka.de
>
>
> This email was sent to you by Thomson Reuters, the global news and  
> information company.
> Any views expressed in this message are those of the individual  
> sender, except where the sender specifically states them to be the  
> views of Thomson Reuters.
>
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> libdbi-users mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-users

Re: [libdbi-users] UNIX Timestamp - DATE to UTC conversion

[Markus H. <mar...@mh...>]

Quoting Ken Ramsay <Ken...@th...>:

>
> Thanks guys,
>
> MySQL defines the field as a DATETIME , so the return type is time_t. As
> far as I could find out, there is no helper funtion to convert this into
> secs from 1 Jan 1970 , so I got around it by using the difftime() call
> and subtracting the returned value from 1/1/1970. difftime() returns the
> difference in seconds.
>
> Not sure it is the most elegant way to do it but it works ...;-}
>

Ah, I see. libdbi provides a dbi_result_get_datetime() function to  
retrieve these time_t values. Unless you have to do it in SQL, you  
could then post-process this value using gmtime() or any other  
suitable Unix time function.

regards,
Markus


-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-users] UNIX Timestamp - DATE to UTC conversion

[Ken R. <Ken...@th...>]

 
Thanks guys,

MySQL defines the field as a DATETIME , so the return type is time_t. As
far as I could find out, there is no helper funtion to convert this into
secs from 1 Jan 1970 , so I got around it by using the difftime() call
and subtracting the returned value from 1/1/1970. difftime() returns the
difference in seconds.

Not sure it is the most elegant way to do it but it works ...;-}

Cheers  



-----Original Message-----
From: Markus Hoenicka [mailto:mar...@mh...] 
Sent: Tuesday, November 18, 2008 5:38 PM
To: Ken Ramsay
Cc: lib...@li...; rr...@ma...
Subject: [libdbi-users] UNIX Timestamp - DATE to UTC conversion

Ken Ramsay writes:
 >           time = dbi_result_get_uint(result,
 > "UNIX_TIMESTAMP(HIST_Timestamp)");

Without actually trying the code: one rough guess is that MySQL does not
return the timestamp as an uint value but as something longer. Did you
try using dbi_result_get_field_type() and
dbi_result_get_field_attrib() to find out which type is returned?

regards,
Markus

--
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de


This email was sent to you by Thomson Reuters, the global news and information company.
Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.

[libdbi-users] UNIX Timestamp - DATE to UTC conversion

[Markus H. <mar...@mh...>]

Ken Ramsay writes:
 >           time = dbi_result_get_uint(result,
 > "UNIX_TIMESTAMP(HIST_Timestamp)");

Without actually trying the code: one rough guess is that MySQL does
not return the timestamp as an uint value but as something longer. Did
you try using dbi_result_get_field_type() and
dbi_result_get_field_attrib() to find out which type is returned?

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-users] UNIX Timestamp - DATE to UTC conversion

[J.J.Green <j.j...@sh...>]

Ken

Shouldn't you have a time_t (unsigned long) for the
time return type (and a dbi_result_get_long or whatever
to extarct it)?

On Mon, 17 Nov 2008, Ken Ramsay wrote:

> Guys
>
> I am trying to get info from a mysql database that stores the date in a
> string format and return UTC format as well as a associated value. I can
> use the following select() statement OK to take care of that :
>             mysql> select UNIX_TIMESTAMP(<Timestamp string>),<data
> fields> from <table>;
>
> This gives all the values in the table and the UTC timeformat
>
> So, next I built libdbi was able to run a simple db connection to test
> it all worked. I then moved on to try the above and got my values OK but
> I get  '0''s for the UTC TIMESTAMP. Anyone any ideas why this doesn't
> work?
>
> Cheers
>
> Here's my src which compiles and runs OK but gives the partial output
> below.. Any ideas ( I have played with the printf statement already ;-)
> ?
>
>
> #include <stdio.h>
> #include </usr/local/include/dbi/dbi.h>
>
> int main() {
>     dbi_conn conn;
>     dbi_result result;
>     unsigned int updateLatency;
>     unsigned int time;
>     const char *name;
>
>     dbi_initialize(NULL);
>     conn = dbi_conn_new("mysql");
>
>     dbi_conn_set_option(conn, "host", "localhost");
>     dbi_conn_set_option(conn, "username", "sqluser");
>     dbi_conn_set_option(conn, "password", "");
>     dbi_conn_set_option(conn, "dbname", "test");
>     dbi_conn_set_option(conn, "encoding", "UTF-8");
>
>     if (dbi_conn_connect(conn) < 0) {
>       printf("Could not connect. Please check the option settings\n");
>     }
>     else {
>       result = dbi_conn_queryf(conn, "select
> UNIX_TIMESTAMP(HIST_Timestamp),HIST_Node,updateLatency from TABLE");
>
>       if (result) {
>         while (dbi_result_next_row(result)) {
>           name = dbi_result_get_string(result, "HIST_Node");
>           time = dbi_result_get_uint(result,
> "UNIX_TIMESTAMP(HIST_Timestamp)");
>           updateLatency = dbi_result_get_uint(result, "updateLatency");
>           printf("%s %d %d\n",name,updateLatency,time);
>         }
>         dbi_result_free(result);
>       }
>       dbi_conn_close(conn);
>     }
>
>     dbi_shutdown();
>
>     return 0;
> }
>
> Sample Output:
>     chimds05 34 0
>     chimds05 12 0
>     chimds05 13 0
>     chimds05 20 0
>     chimds05 10 0
>     chimds05 13 0
>
>
>
> This email was sent to you by Thomson Reuters, the global news and information company.
> Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.
>
>

-- 
J.J. Green, Dept. Applied Mathematics, Hicks Bld.,
University of Sheffield, UK.   +44 (0114) 222 3742
http://sview01.wiredworkplace.net/pub/jjg

Re: [libdbi-users] sqlite and sqlite3 drivers CHAR as TEXT or INTEGER

[Claudiu C. <cl...@cn...>]

On Friday 24 October 2008 14:10:09 João Henrique Freitas wrote:
> Ok
> 
> I can't do a atoi() because is out of my control. But in change the
> struct of table to include a CHAR(1) than CHAR. And I can get CHAR(1)
> like string.

I think you don't think this in C...

-- 
  Claudiu Nicolaie CISMARU
  GNU GPG Key: http://claudiu.targujiu.net/key.gpg
  T: 0755135455
  E: cl...@vi..., cla...@gm...

Re: [libdbi-users] sqlite and sqlite3 drivers CHAR as TEXT or INTEGER

[Markus H. <mar...@mh...>]

Quoting João Henrique Freitas <jo...@gm...>:

> Ok
>
> I can't do a atoi() because is out of my control. But in change the
> struct of table to include a CHAR(1) than CHAR. And I can get CHAR(1)
> like string.
>

I can't claim that this was an ingenious design decision back then as  
it is too long ago to remember for sure. But in retrospect I feel what  
you describe here offers users a choice of how to treat a single char.  
Either as a tiny integer (CHAR) or as a one-byte text [CHAR(1)]. It is  
probably best to keep this behaviour.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-users] sqlite and sqlite3 drivers CHAR as TEXT or INTEGER

[J. H. F. <jo...@gm...>]

Ok

I can't do a atoi() because is out of my control. But in change the
struct of table to include a CHAR(1) than CHAR. And I can get CHAR(1)
like string.

thanks

On Thu, Oct 23, 2008 at 11:10 AM, Claudiu CISMARU
<cl...@vi...> wrote:
>
>> But http://sqlite.org/datatypes.html and
>> http://sqlite.org/datatype3.html says:
>>
>> "The search for these strings in the type declaration is case
>> insensitive, of course. If any of the above strings occur anywhere in
>> the type declaration, then the datatype of the column is text. Notice
>> that the type "VARCHAR" contains "CHAR" as a substring so it is
>> considered text."
>>
>> "If the datatype of the column contains any of the strings "CHAR",
>> "CLOB", or "TEXT" then that column has TEXT affinity. Notice that the
>> type VARCHAR contains the string "CHAR" and is thus assigned TEXT
>> affinity."
>>
>> I think the sqlite and sqlite3 drivers must treat CHAR as TEXT not
>> INTEGER (TINY).
>>
>> It's right?
>
> I don't really think. This text explain how the data it's represented
> internally, inside the sqlite database file, not how it's presented to
> the user. In fact, the driver helps you, transforming that data to a
> numerical value, as you use it in your software. If it remains text,
> then you have to call atoi() on that field to get the numerical value.
>
> --
>  Claudiu Nicolaie CISMARU
>  GNU GPG Key: http://claudiu.targujiu.net/key.gpg
>  T: 0755135455
>  E: cl...@vi..., cla...@gm...
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> libdbi-users mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-users
>
>



-- 
-----------------------------------------------------------
João Henrique Freitas - joaohf_at_gmail.com
Campinas-SP-Brasil
BSD051283
LPI 1
http://www.joaohfreitas.eti.br

Re: [libdbi-users] sqlite and sqlite3 drivers CHAR as TEXT or INTEGER

[Claudiu C. <cl...@cn...>]

> But http://sqlite.org/datatypes.html and 
> http://sqlite.org/datatype3.html says: 
> 
> "The search for these strings in the type declaration is case
> insensitive, of course. If any of the above strings occur anywhere in
> the type declaration, then the datatype of the column is text. Notice
> that the type "VARCHAR" contains "CHAR" as a substring so it is
> considered text."
> 
> "If the datatype of the column contains any of the strings "CHAR",
> "CLOB", or "TEXT" then that column has TEXT affinity. Notice that the
> type VARCHAR contains the string "CHAR" and is thus assigned TEXT
> affinity."
> 
> I think the sqlite and sqlite3 drivers must treat CHAR as TEXT not
> INTEGER (TINY).
> 
> It's right?

I don't really think. This text explain how the data it's represented 
internally, inside the sqlite database file, not how it's presented to 
the user. In fact, the driver helps you, transforming that data to a 
numerical value, as you use it in your software. If it remains text, 
then you have to call atoi() on that field to get the numerical value.

-- 
  Claudiu Nicolaie CISMARU
  GNU GPG Key: http://claudiu.targujiu.net/key.gpg
  T: 0755135455
  E: cl...@vi..., cla...@gm...