Opened 12 years ago

Closed 11 years ago

#1844 closed defect (fixed)

wingrass: db_open_select_cursor fails for DBF driver.

Reported by: martinl Owned by: grass-dev@…
Priority: critical Milestone: 7.0.0
Component: Database Version: unspecified
Keywords: wingrass, dbf Cc:
CPU: Unspecified Platform: MSWindows 2K

Description

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

Change History (9)

comment:1 by martinl, 12 years ago

Milestone: 6.4.37.0.0

comment:2 by mmetz, 12 years ago

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

in reply to:  2 ; comment:3 by hellik, 12 years ago

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

in reply to:  3 ; comment:4 by mmetz, 12 years ago

Replying to hellik:

still valid

still valid ?

in reply to:  4 comment:5 by hellik, 12 years ago

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.

comment:6 by neteler, 11 years ago

Still an issue?

in reply to:  description comment:7 by neteler, 11 years ago

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.

comment:8 by hamish, 11 years ago

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

comment:9 by martinl, 11 years ago

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.