[Gambas-devel] Oh, good grief, it's even worse than I first thought :Re: SHOW STOPPER: GB3, sqlite3 and date fields

Kadaitcha Man nospam.nospam.nospam at ...176...
Mon Dec 14 11:18:51 CET 2009


2009/12/14 Fabien Bodard <gambas.fr at ...176...>:
> Yes your right... no convertion is done as it is commented in
> gb.db.sqlite3 but i don't know why :/ there is certainly a good reason
> in the back ... but it is not 'normal' as gambas need to be able to
> use db natural date/time formats.
>
>                                /*      case ft_Date:
>                                                r->records[sz][i].set_asString(reslt[i]);
>                                                r->records[sz][i].set_asDate(reslt[i]);
>                                                break;*/

Well, mate, I need you to find out why and fix it. This is a major
show stopper. And as for it being commented in gb.db.sqlite3, with all
due respect, I should not be expected to know that.

I could probably work around it by changing the field to NUMERIC, but
then I've got work ahead of me to see if I can store and retrieve
floating point values and convert them to/from human-readable dates in
the user's current default format. I might even opt for a TEXT
datatype if I'm forced to, but then in either case I have to
externally call GNU date to do the conversion to/from the user's
current system date/time format if I want to save myself a stack of
localisation misery. And then there are possibly hundreds of such
conversions to do every second so my freely GPL'd users will have to
invest in several rows of Cray XT5-HE Jaguars with thirty seven
thousand plus Opteron six core 2.6 GHz CPUs each, running in parallel,
but then Gambas isn't multi-threaded, hey.

I mean, this is a really, really big problem.

:(




More information about the Devel mailing list