wingrass: db_open_select_cursor fails for DBF driver.

[martinl]

There is problem with DBF driver on MS Windows. To reproduce this bug run:

db.connect driver=dbf database='$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'
v.random out=n n=3
v.db.addtable map=n columns="class varchar(10)"

It stops at source:grass/trunk/lib/db/dbmi_client/c_openselect.c#L63​

D3/5: db_select_int()
D3/5:   SQL: SELECT cat FROM n
D3/5: SQL statement parsed successfully: SELECT cat FROM n
D2/5: find_table(): table = n
D2/5:   ? n
D2/5: load_table_head(): tab = 0, /opt/grassdata/nc_spm_08_grass7/dbf/dbf//n.dbf
D2/5:   ncols = 2
D2/5:   DBFFieldType 1
D3/5: add_column(): tab = 0, type = 2, name = cat, width = 11, decimals = 0
D2/5:   DBFFieldType 0
D3/5: add_column(): tab = 0, type = 1, name = class, width = 10, decimals = 0
D3/5: Doing SQL command <4> on DBF table... (see include/sqlp.h)
D2/5: SELECT
D2/5: sel(): tab = 0
D2/5: load_table(): tab = 0
D2/5:   ncols = 2 nrows = 0
D2/5: load_table_head(): tab = 0, /opt/grassdata/nc_spm_08_grass7/dbf/dbf//n.dbf

[mmetz]

On Windows,

$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/

should not translate to

/opt/grassdata/nc_spm_08_grass7/dbf/dbf/

because this is not a valid path on Windows.

Can you post the output of g.gisenv?

Markus M

[hellik]

Replying to mmetz:

On Windows,

$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/

should not translate to

/opt/grassdata/nc_spm_08_grass7/dbf/dbf/

because this is not a valid path on Windows.

Can you post the output of g.gisenv?

maybe related ​http://trac.osgeo.org/grass/ticket/1796 ?

​http://trac.osgeo.org/grass/ticket/1796#comment:14

still valid

Helmut

[mmetz]

Replying to hellik:

still valid

still valid ?

[hellik]

Replying to mmetz:

Replying to hellik:

still valid

still valid ?

tested here with

GRASS version: 7.0.svn                                                          
GRASS SVN Revision: 55413                                                       
Build Date: 2013-02-18                                                          
GIS Library Revision: 52468 (2012-07-27)                                        
GDAL/OGR: 1.9.2                                                                 
PROJ.4: 4.8.0                                                                   
GEOS: 3.3.6dev                                                                  
SQLite: 3.7.10                                                                  
Python: 2.7.2                                                                   
wxPython: 2.8.12.1                                                              
Platform: Windows-7-6.1.7601-SP1 (OSGeo4W) 

it works here.

[neteler]

Still an issue?

[neteler]

Replying to martinl:

There is problem with DBF driver on MS Windows. To reproduce this bug run:

db.connect driver=dbf database='$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'

For me (Windows8, version of today, it already hangs here.

[hamish]

One oddity, 'db.connect -p' in trunk expands the $GISDBASE/$L/$M to the full pathname, while the VAR file stores it as the variable. As it is possible to hard-code in the VAR file, by auto-expanding there's no way to tell the difference, and if your current mapset will be portable if you rename or copy the mapset, change the drive it's on, etc.

--

Testing grass7 nightly snapshot from a few days ago on XP, db.connect works ok, but v.db.addtable, v.db.addcolumn, and other v.db.* from the C:\> grass prompt do nothing, just silently return, even with --help or --ui.

echo %errorlevel%

comes back as 9009, which translates to "Program is not recognized as an internal or external command, operable program or batch file".

​http://www.febooti.com/products/automation-workshop/online-help/events/run-dos-cmd-command/exit-codes/

other times just an errorlevel of 0. strange. From the wxGUI menu v.db.addtable worked.

maybe a sometimes bug -> race condition?

From the Msys prompt you can get the program to wake up, but only if you add the .py extension. It seemed to lock up on me for the first try, but then ok? (with dbf/ dir re-removed) when I go to exit I get a traceback from grass.py with _subprocess.INFINITE, "Terminate batch job (Y/N)?"

Hamish

[martinl]

I checked again, and it seems to work with the most recent version from SVN. Closing, please re-open if neeed.