QGIS » QGIS Application

Using the OGR provider (Add Vector Layer) and specifying MySQL database and entering in the parameters of the connection, I'm not using ODBC but I can try this as a workaround to determine the source of the issue.

I experience the same issue. Layers loaded via OGR/MySQL don't get drawn.

To reproduce:

• create mysql db:
  

   echo "CREATE DATABASE qgis_test;" | mysql -u dbuser -p dbpass
  

• import shapefile:
  

   wget http://data.biogeo.ucdavis.edu/data/gadm2/shp/AFG_adm.zip
   unzip -d /tmp/qgistest AFG_adm.zip
   ogr2ogr -f MySQL MySQL:qgis_test,user=dbuser,password='dbpass' /tmp/qgistest/AFG_adm2.shp -nln AFG_adm2 -update -overwrite -lco SPATIAL_INDEX=YES -lco engine=MYISAM -progress -gt 65535
  

• add vector layer in QGIS:
  • Layer -> Add -> Vector
    • Source: Database, Encoding: System
    • Database type: MySQL
    • add/select connection
    • Open

The layer seems to import correctly, but it isn't drawn. Loading the shapefile directly works as expected.

Giovanni Manghi wrote:

I have set up mysql in my linux (ubuntu) box and added the suggested layer.

I then added this layer using qgis 2.4/master on Windows, and it works everything as expected, including editing. So the original issue seems to me that is no longer valid.

Anyway I tested also qgis 2.4/master as client, and in this case I can add the layer, but qgis then immediately crashes:

QGIS died on signal 11Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
No thread selected
No stack.
gdb returned 0
Aborted

Master works fine from Linux and Windows here.

BTW please change kernel.yama.ptrace_scope to 0 in /etc/sysctl.d/10-ptrace.conf (or /etc/sysctl.conf) and run sysctl -p to enable backtraces...

I forgot to mention the QGIS version: I tried master cc5d3bc (I don't get a crash)
MariaDB: 10.0.14 and 5.5.39
GDAL: 1.11.1

I'm beginning to think that this is an OGR error (caused by some mysql/mariadb incompatibility?) ...
OGR_L_GetNextFeature() returns not a single feature for mysql layers but all features for ESRI Shapefile layers.

I nailed it down to gdal/ogr/ogrsf_frmts/mysql/ogrmysqltablelayer.cpp: OGRMySQLTableLayer::BuildWhere() for my case...

there, the query

SELECT `OGR_FID`, `SHAPE` `SHAPE`, `id_0`, `iso`, `name_0`, `id_1`, `name_1`, `id_2`, `name_2`, `varname_2`, `nl_name_2`, `hasc_2`, `cc_2`, `type_2`, `engtype_2`, `validfr_2`, `validto_2`, `remarks_2`, `shape_leng`, `shape_area` FROM `claims` WHERE MBRIntersects(GeomFromText('POLYGON((60,1451354699999996 29,0025819600000005, 75,2538595299999997 29,0025819600000005, 75,2538595299999997 38,8499150399999991, 60,1451354699999996 38,8499150399999991, 60,1451354699999996 29,0025819600000005))'), `SHAPE`);

Notice the ',' decimal separators which are caused by an snprintf() in line 422 respecting my locale. If I start QGIS with

# LC_NUMERIC="C" qgis

everything works as expected.

EDIT: I wonder why there are so many setlocale()s in the code (gdal & QGIS).
LC_NUMERIC is quite often set to "C" and back to the current locale. Is there a reason why LC_NUMERIC isn't kept "C"? Do users expect their local representation in the GUI?
Leaving LC_NUMERIC="C" globally would squash the whole bug class (and save quite some setlocale() calls ;)

please tr y the latest master and report back, there have been big commits that also are affecting improvements with mysql.