Bug report #8435

Spatialite, PostGIS layers with 8-byte primary keys don't display in Identify tool

Added by Brian Freed over 11 years ago. Updated over 10 years ago.

Status:Closed
Priority:Low
Assignee:-
Category:-
Affected QGIS version:1.8.0 Regression?:No
Operating System:Windows Easy fix?:No
Pull Request or Patch supplied:No Resolution:worksforme
Crashes QGIS or corrupts data:No Copied to github as #:17204

Description

Looks like there was an old issue with other layer providers: Issues #6238, #1920, #62, etc. for PostGIS, MSSQL

SQLite only has one INTEGER type for column declaration. It determines whether to store as 4, 6, or 8-byte values.
I have a view in PostGIS with BIGINT primary keys. I'm exporting to a Spatialite database table; since all keys are larger than the 4-byte limit, I assume SQLite is using 8-byte storage.

When I load the PostGIS view in QGIS, the rows show correctly in the Attribute Table.
When I load the Spatialite table in QGIS, the rows display a negative number for the primary key column.

In both cases, the Identify Features tool fails to do anything.
With Spatialite it fails silently.
With PostGIS I get a Log Message like 'feature -148753075 not found' (the actual primary key is a very large positive number)

After some digging, I found a workaround I'll try next:
http://linfiniti.com/2011/11/adding-a-counter-to-postgresql-query-results/

Since there's a workaround, I'm picking 'low priority'.
If it's an inherent Qt limitation, maybe QGIS could raise a prompt with advice, to avoid users re-searching a known problem.

History

#1 Updated by Giovanni Manghi over 11 years ago

  • Status changed from Open to Feedback

have you tested qgis master?

#2 Updated by Jürgen Fischer over 10 years ago

  • Resolution set to worksforme
  • Status changed from Feedback to Closed

closing for the lack of feedback.

Also available in: Atom PDF