May get complex, though. Because names prefixed with "j_" can still collide with existing field names (imagine someone importing a Shapefile with fields that already have that prefix). And then we will have to think of some really clever ways to avoid name collisions.
My suggestion: 1. When exporting a shapefile, check if the are any duplicates in the (truncated) output field names 2. If no: just export, do not add any prefixes 3. If yes: give the user a choice to Cancel and fix names manually or drop the duplicate fields on export (the same may need to be applied for saving plain DBF tables, so these logics should go into the DBF table handling, not the shapefile export functions) Btw.: if all this DBF mess gets too much, how about migrating the project to a proper PostGIS DBMS? Ben ----- Original Message ----- From: "Juan Ignacio Varela García (Nacho Uve)" <[email protected]> To: "Users and Developers mailing list" <[email protected]> Sent: Wednesday, December 23, 2009 1:19:36 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [Gvsig_english] Export Shapefile behaviour with Joined Tables +1 2009/12/22 Simon Cropper (Botanicus Australia Pty Ltd) < [email protected] > Hi, This is another - "it would be better" issues. When you join two tables and then export the shapefile to "hard code" the information so to speak. Despite having unique names the resulting attribute table to the exported shapefile has "j_" in front of all the field names. This is frustrating because if you have a field name, like I did, Active2005, Active2007 and Active2009 once this prefix is added the resulting table has tree fields called "J_ACTIVE20" as the fields are truncated to 10 characters. I suppose I could understand this behaviour if you have duplicate fields in the original joined table (i.e. the use of a prefix) but the creation of a table that has duplicate field names is a violation of the rules around DBFs (i.e. you can't have two fields the same). The export facility should review the output file's attribute table names and confirm that duplicate names have not been generated. Personally, I think that if you have a joined table and no fields have the same name then the exported table should just be a reflection of this - i.e. the "J_" should not be inserted. -- Cheers Simon Simon Cropper Botanicus Australia Pty Ltd PO Box 160, Sunshine, Victoria 3020. P: 9311 5822. M: 041 830 3437. mailto: [email protected] <mailto: [email protected] > web: www.botanicusaustralia.com.au < http://www.botanicusaustralia.com.au > _______________________________________________ Gvsig_internacional mailing list [email protected] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional -- Juan Ignacio Varela García (Nacho Uve) Coordinador Grupo de Desarrollo Cartolab - Laboratorio de Ingeniería Cartográfica http://www.cartolab.es ETS Ingeniería de Caminos, Canales y Puertos Universidade da Coruña Campus de Elviña - 15071 A Coruña (España) (34)981167000 ext. 5493 _______________________________________________ Gvsig_internacional mailing list [email protected] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional ------ Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. _______________________________________________ Gvsig_internacional mailing list [email protected] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
