Hello > I've got a first implementation available for testing in CVS. There > are only get_as* functions at this time as I'm still struggling with > the bind* interface. The new functions can be admired by running "make > check" in libdbi-drivers. That is, you'll need the CVS versions of > both libdbi and libdbi-drivers. >
Excelent, I read the new functions but not test yet. Many thanks. > The conversions are currently done as follows: > > get_as_string_copy/get_as_string_copy_idx (returns allocated buffer) > integers: rendered by sprintf > float and double: rendered by sprintf > strings: as is. NULL strings are returned as empty strings though. > binary strings: returned as empty strings Why binary strings return empty? If I define a column like: CREATE TABLE Filename ( FilenameId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, Name BLOB NOT NULL, PRIMARY KEY(FilenameId), INDEX (Name(255)) ); "Name" is type binary has a string like "xorg.conf". You see any problem if binary does not return a string? Yes, binary data could be a image. It will only return a without sense string. > date and time: pretty-printed as YYYY-MM-DD HH:MM:SS. Date-only values will > show an allballs time, and time-only values will claim 1970-01-01 (the start > date of the Unix epoch) as date. > > get_as_longlong/get_as_longlong_idx (returns long long integer value) > integers: typecast to long long > float and double: typecast to long long. Remember that float and > double values easily exceed the range of long long. Currently there is > no such thing as an overflow error flag. > strings: rendered by strtoll(). If the string contains a number as > understood by that function, its value is returned. NULL strings, > empty strings, and strings that cannot be parsed as a number return 0. > binary strings: returned as 0 > date and time: returned as number of seconds elapsed since the Unix > epoch. Time-only values will be calculated as of 1970-01-01, and > date-only values will indicate the number of seconds elapsed at > midnight (the first second of the given date). > > All in all, these new functions are certainly no "one-size-fits-all" > solution for retrieving field values without knowing the types of the > fields, but they may be convenient in many cases. Please let me know > if these defaults don't seem reasonable, or if we should attempt to > report overflows, unconvertible values etc. with error flags. > > Ok, I'll report my tests soon Thanks > > regards, > Markus > > -- > Markus Hoenicka > [EMAIL PROTECTED] > (Spam-protected email: replace the quadrupeds with "mhoenicka") > http://www.mhoenicka.de > -- ----------------------------------------------------------- João Henrique Freitas - joaohf_at_gmail.com Campinas-SP-Brasil BSD051283 LPI 1 http://joaohf.pbwiki.com http://www.livejournal.com/users/joaohf/ ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
