gvSIG bugs #2871
Error when the position of a field is changed in a table
| Status: | Closed | % Done: | 0% | |
|---|---|---|---|---|
| Priority: | Normal | Spent time: | - | |
| Assignee: | - | |||
| Category: | Document table | |||
| Target version: | - | |||
| Severity: | Minor | Add-on version: | ||
| gvSIG version: | 2.1.0 | Add-on build: | ||
| gvSIG build: | 2247 | Add-on resolve version: | ||
| Operative System: | Add-on resolve build: | |||
| Keywords: | Proyecto: | |||
| Has patch: | Hito: | |||
| Add-on name: | Unknown |
Description
When a field is changed to another position in a table (dragging it), the type of the field is changed. It takes the type of the previous field in that position.
Example:
- We have FIELD1 (string), FIELD2, FIELD3 (integer) with different values.
- We move the FIELD3 to the second position.
- Then the values change from integer to double.
It memorizes the type of every field in the initial position and the types are always the same.
History
#1
Updated by Antonio Falciano over 9 years ago
Hi Mario,
I can reproduce this issue. Fortunately the dragging of a field is only apparent doesn't produce the alteration of the table. For instance, if you drag a whatever field in an attribute table, close the table and export the layer, then the attribute table of the exported layer will be the original one, so the field definitions are not altered at all. Although, in order to avoid confusion, it's convenient to not allow to drag the fields in a table.
#2
Updated by Álvaro Anguix over 9 years ago
- Category set to Document table