[GRASS-dev] [GRASS GIS] #1844: wingrass: db_open_select_cursor fails for DBF driver.

GRASS GIS trac at osgeo.org
Sat Jun 29 20:22:31 PDT 2013

#1844: wingrass: db_open_select_cursor fails for DBF driver.
 Reporter:  martinl        |       Owner:  grass-dev@…              
     Type:  defect         |      Status:  new                      
 Priority:  critical       |   Milestone:  7.0.0                    
Component:  Database       |     Version:  unspecified              
 Keywords:  wingrass, dbf  |    Platform:  MSWindows 2K             
      Cpu:  Unspecified    |  

Comment(by 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

  echo %errorlevel%

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

 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)?"


Ticket URL: <https://trac.osgeo.org/grass/ticket/1844#comment:8>
GRASS GIS <http://grass.osgeo.org>

More information about the grass-dev mailing list