You get zeros, while it should return 0.0000001. If I examine the dbf
in oocalc, there are zeros indeed!
Moreover, even when I create a datable some other way (eg. a dbf in
oocalc) and it has numbers with 7 decimal places stored, d.what.vect,
v.to.db, v.db.select round the output down, so that eg. 0.0000001
becomes 0.
You get zeros, while it should return 0.0000001. If I examine the dbf
in oocalc, there are zeros indeed!
Moreover, even when I create a datable some other way (eg. a dbf in
oocalc) and it has numbers with 7 decimal places stored, d.what.vect,
v.to.db, v.db.select round the output down, so that eg. 0.0000001
becomes 0.
Looks like a silent data corruption.
this is 6.3-cvs, not 6.0.2, correct?
In dbmi_base/valuefmt.c, 6.3-cvs uses:
db_convert_value_to_string()
..
case DB_C_TYPE_DOUBLE:
sprintf (buf, "%lf",db_get_value_double(value));
G_trim_decimal(buf);
break;
this prints to many many decimal places (~30?) then trims off trailing
zeros any time a value is read from a DOUBLE column in the DB table.
GRASS 6.0.2 just printed six places after the decimal point.
(but still "%lf" ? I feel I'm still leaving something out.......?)
If this is 6.3, maybe there is somewhere else in the code which needs
"%lf" + G_trim_decimal()? [db_convert_Cstring_to_value() ?]