[GRASS-dev] string madness

[Markus Neteler]

On Sat, Mar 17, 2007 at 07:37:48PM +0000, Glynn Clements wrote:
> Markus Neteler wrote:
> 
> > > >Apparently the db_set_string() fails.
> > > >Adding debug output to db_set_string() in lib/db/dbmi_base/string.c
> > > >shows that the date string does not "reach" db_set_string() above.
> > > >Maybe the '-' chars in 2001-04-03 are evil for db_set_string()?
> > > 
> > > What reaches db_set_string()? NULL?
> > 
> > err, how to find out?
> > With 'ddd' I never reach any DBMI code, it get's me into
> > XDR and then I receive the result. "step" doesn't step into
> > DBMI.
> 
> The DBMI drivers run as separate processes. You would need to first
> debug the client (db.select) up to the point where it starts the
> driver (db_start_driver), then start debugging driver/db/sqlite,
> attaching to the child process. Once you've attached, you need to
> allow the client to continue running.

I debugged db.select but then bailed out when reaching XDR.
I am not sure how to attach to a child process (I am using 'ddd').
Maybe some notes could be added to
http://grass.gdf-hannover.de/wiki/GRASS_Debugging
(to avoid future questions) - or I can add notes once I know
how to do it.
 
> But in this case, I think that the problem is that the common
> dbmi_driver code is reading value->t (because the column has type
> datetime) and sending that to the client, but the SQLite
> implementation of db__driver_fetch (db/drivers/sqlite/fetch.c) is
> filling in value->s (because the data is stored as SQLITE_TEXT).

Ah, this detail I was missing. Looking at the Postgresql driver, I
see that now - didn't remember that value->t was there. I was sort
of blind when looking at include/dbmi.h.

> To fix this, the SQLite driver would need to check the column type

That's easy, in my local version it was already there.
Now in CVS.

> reported to the client (sqltype) rather than the type used within
> SQLite (litetype), and parse the textual form into the value->t field
> (of type dbDateTime).

I have added this in CVS now, inspired by the Postgresql driver.
It still doesn't work, sigh. Still no date output in db.select.

> I can't really look into this much further, as I don't have SQLite
> installed here.

Sure, no problem. 
It would be very helpful to have a function to simply print
the current content of the value structure. Maybe it is just
to make a function to print more or less the results of:

grep return lib/db/dbmi_base/value.c | grep value
?

Anyway, I assume that value->t is populated now and that the
content gets lost later.

Markus