[Gvsig_english] Export Shapefile behaviour with Joined Tables

[Simon Cropper (Botanicus Australia Pty Ltd)]

Hi,

Follow up observations...

I have found the "import fields" options. Despite this I still think 
that the export behaviour is inappropriate, especially as it creates a 
table that violates fundamental rules.

I used the "import fields" option and it worked quite well except for 
the following minor bug.

Note that when you change the name in the field listing by inserting a 
character at the start of a name the cursor moves to the end of editbox.

As mentioned I had problems with Active2005 being renamed J_Active20 
when exporting. To avoid the truncation of the field name I called it 
A2005. However since my programs searches for Active2005 I wished to 
edit the field name back to the original name. So I clicked between "A" 
and "2" and typed "ctive" -- what I ended up with was "Ac2005tive", 
because once I inserted the first character the cursor automatically 
went to the end. Following the insertion of any character within the 
editbox the cursor is automatically sent to the end.

Cheers Simon

Simon Cropper
Botanicus Australia Pty Ltd
PO Box 160, Sunshine, Victoria 3020.
P: 9311 5822. M: 041 830 3437.
mailto: scropper at botanicusaustralia.com.au 
<mailto:scropper at botanicusaustralia.com.au>
web: www.botanicusaustralia.com.au <http://www.botanicusaustralia.com.au>



Simon Cropper (Botanicus Australia Pty Ltd) wrote:
> 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.
>