#1245: v.db.connect parsing
-----------------------------------+----------------------------------------
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.1
Component: Vector | Version: svn-releasebranch64
Keywords: v.db.connect, scripts | Platform: All
Cpu: All |
-----------------------------------+----------------------------------------
Hi,
just a placeholder bug report for the records; as reported on the mailing
list.
sqlite+v.in.ogr adds a table name to the table number reported by
v.db.connect -p,-g as "number/name". So if parsing for the table number we
need to use the -l flag as well to suppress the name.
the following shell scripts are affected, need to check the python
scripts/lib for this too.
#1245: v.db.connect parsing
-----------------------------------+----------------------------------------
Reporter: hamish | Owner: hamish
Type: defect | Status: assigned
Priority: major | Milestone: 6.4.1
Component: Vector | Version: svn-releasebranch64
Keywords: v.db.connect, scripts | Platform: All
Cpu: All |
-----------------------------------+----------------------------------------
Description changed by hamish:
Old description:
Hi,
just a placeholder bug report for the records; as reported on the mailing
list.
sqlite+v.in.ogr adds a table name to the table number reported by
v.db.connect -p,-g as "number/name". So if parsing for the table number
we need to use the -l flag as well to suppress the name.
the following shell scripts are affected, need to check the python
scripts/lib for this too.
just a placeholder bug report for the records; as reported on the mailing
list.
sqlite+v.in.ogr adds a table name to the table number reported by
v.db.connect -p,-g as "number/name". So if parsing for the table number we
need to use the -l flag as well to suppress the name.
the following shell scripts are affected, need to check the python
scripts/lib for this too.
Replying to [comment:6 neteler]:
> Hamish, what about the 6.4 backport?
as it was not a simple incisive change, before backporting I thought to
leave it in 6.5svn for a while in case there were any typos.
aka I haven't tested the changes to see if they still work.
other than that, no reason not to backport. (not being lazy with
backports; I try not to backport anything I haven't tested. so just being
lazy with testing
