Bug report #2629
fTools fail to rename duplicated field names if they are 10 char long
|Affected QGIS version:||
|Pull Request or Patch supplied:||
|Crashes QGIS or corrupts data:||
||Copied to github as #:||12689
If I join two tables containing common 10-char-long field name, fTools try to add the "_" char to one of them, then truncate it and fail to write, with no warning message. Could it rename the field name in a more robust way or at least warn that the layer won't be created and why?
I've just realized it's a common issue in all fTools.
This is not an fTools issue, this is limitation of ESRI Shapefile format (exactly DBF format). Field name must be <= 10 characters.
Here is patch to add some warnings to the "Join by attributes" and "Spatial join" tools
The warnings are necessary, but I still suggest to truncate names to 8 characters before adding the suffix. It's extremely easy to implement and can help in many cases (not in all, of course).
Ok, here is another patch. Long names are truncated to 8 characters and then suffix added. But in this case warning are not necessary I think and we can remove it.
They're still necessary, as one can have more than 2 affected fields. E.g. both "foobarfoo1" and "foobarfoo2" in both tables. It would be the best to add a computed suffix _(n+1) (thought it's still not ideal, as it could cause confusions)
Replying to [comment:6 borysiasty]:
It would be the best to add a computed suffix _(n+1) (thought it's still not ideal, as it could cause confusions)
As far as I see computed suffixes _(n+1) are used
Sorry, my fault! I've look too briefly into the code!
Anyway, I believe we should keep the warnings for a case if one has more than 9 very long names with common prefix in a non-dbf table (e.g. fobarfoo_temperature, fobarfoo_precipitation etc).
- Resolution set to fixed
- Status changed from Open to Closed
Patch applied in 71a9f815 (SVN r13314).
Also available in: Atom