[GRASS-user] Error in sqlite3_step()

[Dylan Beaudette]

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
<mlennert at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>