[GRASS-dev] string madness
Glynn Clements
glynn at gclements.plus.com
Sat Mar 17 15:37:48 EDT 2007
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.
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).
To fix this, the SQLite driver would need to check the column type
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 can't really look into this much further, as I don't have SQLite
installed here.
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list