[GRASS-dev] string madness

[Glynn Clements]

Markus Neteler wrote:

> 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.

I haven't used DDD in years. In gdb, you use "attach <pid>" to attach
to an existing process.

> > 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.

	switch ( litetype ) {
	    case SQLITE_TEXT:
		if (sqltype == 6 ) { /* date string */

I don't know where that 6 comes from; it should probably be
DB_SQL_TYPE_DATE (which is 9).

However, having looked at this some more, I don't see how you can have
a "date" column in an SQLite database. The SQLite driver's version of
db__driver_create_table() just creates a "text" column, with no
indication that the column actually contains dates. Unless *something*
is storing the fact that the column contains dates, the value should
simply be treated as text.

What does db.describe have to say about the table?

-- 
Glynn Clements <glynn at gclements.plus.com>