5

Within QGIS, I joined .dbf table containing population data to a shapefile of Census tracts. The join field is called GISJOIN in both the target table and the shapefile's table, and this attribute has the "string" data type in both tables. When I look at the attribute table of the population table after it is loaded within QGIS, all the data is there and looks fine. When I compare the values of the GISJOIN fields in each table to each other, they match up perfectly.

HOWEVER when I perform the join, inside the Properties dialog, and then look at the shapefile's attribute table, all the new attribute headings are there, added in, but all the values are "NULL."

Any idea what is going on here?

Improve this question
5
  • 1
    It appears that QGIS is performing the join, but the GISJOIN field is not actually joining. Are you sure the IDs match (same number of digits, no padding spaces or zeros, etc.)? – Darren Cope Jun 18 '13 at 15:55
  • In ArcGIS this can happen where: 1) the values aren't perfect matches as noted in the prior comment, 2) the name of the table or feature class, or field names in the table or feature class, include spaces or special characters, or 3) field names are reserved words. – johns Jun 18 '13 at 17:02
  • Thanks Darren and johns. I'm still scratching my head. The IDs definitely match perfectly. (And both datasets come from the same source -- National Historical GIS -- so it makes sense that they would.) The only additional item I would note is that when I again examined the .dbf files (in OpenOffice), I see that each of the field names have some sort of code following them including a letter, commas, and a number. For example: GISJOIN,C,12 These codes don't show up in the attribute tables within QGIS however. The codes for each table's GISJOIN field do match. Could these codes create problems? – Abijah Jun 19 '13 at 9:24
  • Did you see this: assets.nhgis.org/… It appears there are two sets of downloads, one being comma delimited (best for GIS) and one for with a descriptive header row that is best for spreadsheets. – johns Jun 19 '13 at 13:13
  • Abijah; the codes in OpenOffice are fine; that's just how it is displaying the field type and length of the .dbf. Of course you may have an issue if the field type is not the same in the shapefile and the .dbf. If this is the case, Johns' solution may work -- try the .csv and see if that solves your problem. You could also try saving from .dbf to .csv in OpenOffice. – Darren Cope Jun 19 '13 at 15:44
4

Even if it's late but the response can be useful...

When you join the fields between your .csv and your .shp (for example), be sure that the Type are the same (see in Properties of both file).

For example: my FID for my shp was in real as my ID for my csv was in integer. After the join, I get "NULL". But after changing the type (I created a new ID column in my shp) it worked perfectly.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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