Yeah. I have recently noticed this type of behavior after switching to sqlite. I was unable to patch two vectors (and att tables) after defining new columns of type varchar(20). I re-made the columns as 'text' and v.patch worked as expected. Maybe we need some special, internal conversions (varchar ---> text) when working with sqlite db.
Cheers, Dylan On Mon, Apr 6, 2009 at 2:58 AM, Moritz Lennert <mlenn...@club.worldonline.be> wrote: > On 06/04/09 11:41, Moritz Lennert wrote: >> >> On 03/04/09 17:06, Craig Leat wrote: >>> >>> Moritz Lennert wrote: >>>> >>>> Don't have time to look into this now, but it must be a problem in the >>>> special sqlite implementation in that script: >>>> >>>> if [ "$driver" = "sqlite" ] ; then >>>> #echo "Using special trick for SQLite" >>>> # http://www.sqlite.org/faq.html#q13 >>>> v.info --q -c map=$GIS_OPT_MAP layer=$GIS_OPT_LAYER | cut -d'|' >>>> -f1,2 >>>> | grep -v "|${col}$" > "$TMP.coldesc" >>>> # need to revert order: >>>> cat "$TMP.coldesc" | cut -d'|' -f1 > "$TMP.coltypes" >>>> cat "$TMP.coldesc" | cut -d'|' -f2 > "$TMP.colnames" >>>> COLDEF=`paste -d' ' "$TMP.colnames" "$TMP.coltypes" | tr '\n' ',' >>>> | >>>> sed 's+,$++g'` >>>> COLNAMES=`cat "$TMP.colnames" | tr '\n' ',' | sed 's+,$++g'` >>>> echo "BEGIN TRANSACTION; >>>> CREATE TEMPORARY TABLE ${table}_backup(${COLDEF}); >>>> INSERT INTO ${table}_backup SELECT ${COLNAMES} FROM ${table}; >>>> DROP TABLE ${table}; >>>> CREATE TABLE ${table}(${COLDEF}); >>>> INSERT INTO ${table} SELECT ${COLNAMES} FROM ${table}_backup; >>>> DROP TABLE ${table}_backup; >>>> COMMIT;" > "$TMP" >>>> db.execute input="$TMP" >>> >>> My execute statement looks like this: >>> BEGIN TRANSACTION; >>> CREATE TEMPORARY TABLE SBC2_backup(cat INTEGER,LM CHARACTER,WARD >>> INTEGER,CLASS_NAME CHARACTER); >>> INSERT INTO SBC2_backup SELECT cat,LM,WARD,CLASS_NAME FROM SBC2; >>> DROP TABLE SBC2; >>> CREATE TABLE SBC2(cat INTEGER,LM CHARACTER,WARD INTEGER,CLASS_NAME >>> CHARACTER); >>> INSERT INTO SBC2 SELECT cat,LM,WARD,CLASS_NAME FROM SBC2_backup; >>> DROP TABLE SBC2_backup; >>> COMMIT; >>> >>> Why does v.db.dropcol define a type CHARACTER when sqlite3 supports >>> (NULL, INTEGER, REAL, TEXT, BLOB)? >> >> v.db.dropcol just uses the output of v.info -c, and AFAIR, SBC2 has its >> columns defined as CHARACTER, or ? > > See also this thread: > > http://lists.osgeo.org/pipermail/grass-user/2009-January/048281.html > > Moritz > _______________________________________________ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user