WinQGIS: GRASS vector does not see the table associated

[lami@…]

If you click on a the "Open table" buttom or if use the pointer on a element of a GRASS vector you can not see any informations about the linked table, only the ids and categories. It works well with the OGR vectors.

[rblazek]

Probably either GISBASE is not set correctly or database driver is missing. Which driver is used? Can you use db.* modules from shell? What errors are printed

Radim

[rblazek]

We mark critical only the bugs crashing QGIS.

Radim

[anonymous]

Hi Radim, If I use db.* I have this outputs:

Linux@PORTATILE ~ $ db.tables.exe grotte_dist

Linux@PORTATILE ~ $ db.connect -p driver:dbf database:$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ schema:(null) group:(null)

The dbln file of a sample vector is: 1 gps_etrex cat $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ dbf

I don't see anythings wrong but I'm not sure if forget somethings

[rblazek]

Yes, but db.select etc?

Radim

[lami@…]

If I make db.select table=grotte_dist

I can see all the data stored in the table

[rblazek]

I can confirm the problem with http://qgis.org/uploadfiles/testbuilds/qgis_setup.exe (15.12.2006 9:45 CET) installed in directory without spaces. I works however with my old cross compiled version so either the bug was introduced recently or it is a problem with MinGW/Windows.

This must be fix for release IMO otherwise all GRASS is useless.

Radim

[rblazek]

It does work if qgis is started from MSYS shell (which was not started from QGIS GRASS Tools so GISBASE and GISRC are not set but it works also if MSYS was started from QGIS) and it does not work if qgis is started from command.com.

It means that it depends how QGIS was started. MSYS shell has maybe some variables set or it emulates(?) somehow something (?) which was compiled in with crosscompiler????

Radim

[rblazek]

According to Filemon QGIS does not even try to access dbf.exe. A GRASS database driver is started as separate process, on Windows it is started with _spawnl( _P_NOWAIT, startup, "", NULL ). Can it be possible that _spawnl is somehow restricted under certain circumstances for security reasons? QProcess is using CreateProcessA/CreateProcessW to start a process.

Radim

[rblazek]

The problem is that if QGIS is not run/compiled as command line application it does not have stdout/stdin open and db_start_driver function (grass/lib/db/dbmi_client/start.c) fails here:

   if ( (stdin_orig  = _dup(_fileno(stdin ))) == -1  ||
         (stdout_orig = _dup(_fileno(stdout))) == -1 )
    {
        db_syserror ("can't duplicate stdin/stdout");
        return (dbDriver *) NULL;
    }

Radim

[rblazek]

The patch for grass/lib/db/dbmi_client/start.c start.c.patch1 which fixes this ticket is attached.

Unfortunately if QGIS is not compiled without stdin/stdout and then run from batch, cmd.exe or MSYS shell it will open command window for a while always when a new GRASS database driver is started.

This ticket is fixed but I leave it open until developers who build win binary patch their version of GRASS.

Radim

[rblazek]

Replying to rblazek:

Unfortunately if QGIS is not compiled without stdin/stdout

Should be : if QGIS is compiled without stdin/stdout

Radim

[neteler@…]

Patch applied.

Markus

[timlinux]

If the patch is applied in grass cvs head we can just update from cvs and rebuild grass. Or is there a particular feeling that we should use only grass stable release along with qgis 0.8?

[neteler@…]

The patch was applied to GRASS cvs head. All recent Windows fixes were only done there.

Markus

[neteler@…]

Now also applied to 6.2-CVS release branch. However, this branch is lacking tons of Windows fixes which were done in CVS HEAD only.

Markus

[timlinux]

I have this resolved in the QGIS windows binary installer I am making. I built grass under msys with the above mentioned patch.

[anonymous]

Milestone Version 0.8 deleted