Feature request #11888
Warn the user when OGR "stretched" the column width to accommodate values
Status: | Open | ||
---|---|---|---|
Priority: | High | ||
Assignee: | - | ||
Category: | Vectors | ||
Pull Request or Patch supplied: | No | Resolution: | |
Easy fix?: | No | Copied to github as #: | 20102 |
Description
Hi all,
i stumble over 2 Issues editing Attributes:
First:
Step 1: I create a new Shapefile, then add 2 attribute columns (Type String, one length 50 and one length 5).
Step 2: Then I add a Feature to the Shapefile and set the first attribute to "First Value". Now I calculate the second one using the field calculator and set the second column = first column. Result: "First Value" ist written into the 2. column but I think it should be cut at Position 5 to "First"... It seems that the field length get automaticaly extended to the length of the first field.
Second:
If I fill in a 50 chars Text containing one "ä" or a "ö" or a "ü" (german special characters) to Field 1, and then save it, close Qgis, reopen it and load the shapefile into Qgis again then the length of Field 1 is extended to 51.
Thanks
Peter
History
#1 Updated by Giovanni Manghi almost 10 years ago
- Status changed from Open to Feedback
about the first issue:
I filed a ticket while a ogr with the same description, and it turns out that is a new ogr feature, if thee column width does not fit the value is being computed it is automatically enlarged.
the second issue seems related, anyway I'm not able to replicate here locally.
closing?
#2 Updated by Peter Drexel almost 10 years ago
Hi Giovanni,
I just tried Version 2.6.1 (Windows 7 64 bit), issues are the same.
Specialy the second one is really bad, because the fieldlegth of an exisiting field may be changed by simply entering a special character instead of a "normal" one. (For example changing from "Munchen" to "München").
For the First Issue there should be at least a Warning message, because we run into troubles when we accidentally change the Table structure...
Thanks
Peter
#3 Updated by Giovanni Manghi almost 10 years ago
Peter Drexel wrote:
Hi Giovanni,
I just tried Version 2.6.1 (Windows 7 64 bit), issues are the same.
Specialy the second one is really bad, because the fieldlegth of an exisiting field may be changed by simply entering a special character instead of a "normal" one. (For example changing from "Munchen" to "München").
I cannot replicate here, please attach sample data and or detailed steps on how replicate.
For the First Issue there should be at least a Warning message, because we run into troubles when we accidentally change the Table structure...
feel free to open a feature request.
#4 Updated by Peter Drexel almost 10 years ago
Hi Giovanni,
it hapens with New Shapefiles with UTF-8-Encoding.
Create New Shapefile with UTF-8 Encoding, add a textfield (width 5) and save it as "a.shp"
Start editing "a.shp", add a point and fill the textfield wit "ööööö" (german oe).
Stop editing, save "a.shp".
Unload "a.shp", reload "a.shp", check the properties of the fields of "a.shp" - in my case the textfield now has a width of 10.
Thanks
Peter
#5 Updated by Giovanni Manghi almost 10 years ago
- Status changed from Feedback to Open
- Category changed from Attribute table to Vectors
- Tracker changed from Bug report to Feature request
- Subject changed from Edit attributetable of a shapefile, qgis automaticaly change field length to Warn the user when OGR "stretched" the column width to accommodate values
- OS version deleted (
64 bit) - Operating System deleted (
Windows 7) - Target version changed from Version 2.8 to Future Release - Nice to have
Peter Drexel wrote:
Hi Giovanni,
it hapens with New Shapefiles with UTF-8-Encoding.
Create New Shapefile with UTF-8 Encoding, add a textfield (width 5) and save it as "a.shp"
Start editing "a.shp", add a point and fill the textfield wit "ööööö" (german oe).
Stop editing, save "a.shp".
Unload "a.shp", reload "a.shp", check the properties of the fields of "a.shp" - in my case the textfield now has a width of 10.
Thanks
Peter
it happens also if you update/fill a column using just ogrinfo (no QGIS involved), so it is always this new OGR feature that "causes" this issue. I agree that maybe QGIS should warn the user when the column is being "stretched", but this is an improvement over a (now) expected behavior that was introduced by a library that is not a QGIS one.
#6 Updated by Giovanni Manghi over 7 years ago
- Easy fix? set to No