I am running QGIS 1.8. I have a layer from an ESRI Personal GDB. There are 431 features in the layer. When you load the layer into QGIS, and look at the Metadata properties, it shows the number of features as 431. layer metadata

When I open the attribute table, the table only shows 180 features. Layer attribute table

This is a layer that had been loaded in straight from the Personal GDB. No filters or queries had been added to it, so all features should be showing.

I first came across this issue because another coworker was trying to access the same layer using QGIS 1.7. He was having the same issue.

A couple items of note:

  1. This layer was existing in the PGDB, and then using ArcGIS, I copied and replaced a new version from a File GDB into the PGDB.
  2. I am able to load other layers from the same PGDB into QGIS where all the features are displayed.
  3. The PGDB is a modified MS Access database. If you open the database with MS Access, then open the table for this layer, it contains all 431 records with attributes.

Here is a screenshot of the layer in QGIS: QGIS Screenshot

Here is a screenshot of the same layer in ArcGIS: ArcMap Screenshot

If anyone has some insight into why QGIS is able to see the actual number of features in the layer, but is only displaying a certain number, I would appreciate it.

  • 1
    My guess would be that the count is stored in the file header (also for r/w offsets) and is not actually constructed by counting each time. No idea what went wrong though. Commented Sep 15, 2012 at 9:23
  • @lynxlynxlynx - I edited the post to say that if you open the PGDB with MS Access, the table for this layer contains all 431 records and attributes. Commented Sep 15, 2012 at 10:15
  • 2
    In MS Access, how does the 181st record look? Could it have some untrapped error or special character?
    – andytilia
    Commented Sep 15, 2012 at 11:00
  • @andytilia - It looks like we have a winner. The coordinates for 181 seem to be nonexistent. Looking through the rest of the table, there are a few others as well. If you were to post that as an answer, I'd be happy to give you credit for it. Commented Sep 17, 2012 at 16:34

2 Answers 2


Open the Personal GDB in MS Access to make sure the records not shown in QGIS all have valid data, including coordinates. I'd first check the 181st record (in your case), being the first record not shown in QGIS.

Given your confirmation in the comment above, you might file a bug with the QGIS team to request a visible error message in case invalid data is found.

  • 1
    Hm. I think it's a bug. Or is it a feature request?
    – andytilia
    Commented Sep 17, 2012 at 17:45

Probably one of the feature's geometries is failing to hydrate. Can you print all of the geometries with ogrinfo -al datasource

  • Not sure what you mean by failing to hydrate. Upon further investigation, a number of the features have no spatial data. It seems that the record was added to the attribute table, with no spatial data being encoded in the shape field. Interesting that the same layer, with the same features in a File GDB, loads all 431 features, and simply does not display those missing spatial data, where the Personal GDB stops loading at the first feature with an error. Commented Sep 17, 2012 at 22:59
  • To answer your question directly, running ogrinfo -al datasource only loads the first 180 records. That is, it loads the records until it hits the first record with an error in the spatial data. Running ogrinfo datasource layer -where "OBJECTID=183", which is the next valid point, correctly lists the data for that record. This indicates that it is able to read the subsequent, valid, records, but not all of them in a row. Commented Sep 17, 2012 at 23:14
  • so basically the qgis reader is stopping at the first error instead of just skipping the errors (similar to the --skipfailures ogr2ogr flag. It looks like an enhancement request / bug fix. Commented Sep 18, 2012 at 0:09
  • 1
    Created Bug report: hub.qgis.org/issues/6368 Commented Sep 18, 2012 at 22:54
  • cool. This is the only way that open source products get better - when users submit good bug reports. +1 Commented Sep 20, 2012 at 17:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.