Bug report #2010
wrong values inserted on the table
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  nobody - | ||
| Category: | Data Provider | ||
| Affected QGIS version: | Regression?: | No | |
| Operating System: | All | Easy fix?: | No |
| Pull Request or Patch supplied: | Resolution: | invalid | |
| Crashes QGIS or corrupts data: | Copied to github as #: | 12070 |
Description
If I try to add values with decimals in the last column of the attached table, I get weird results. If the same values are added via an external program (a spreadsheet), they show up fine, so it may be the commit that fails.
r11800
History
#1
Updated by Giovanni Manghi over 14 years ago
Hi Paolo,
this is what I see under qgis 1.3 with this shape:
-) numbers with decimals are added and shown correctly after committing the changes
-) if the number I add has the integer part that is > 2 numbers, than the decimal part is always stripped, but I guess that this may depend about the properties of the column
-) I'm not allowed to use "," as decimal separator in qgis
#2
Updated by Giovanni Manghi over 14 years ago
I'm pretty sure that I have pointed the follwoing behaviour in another ticket, but I can't find it now.
When a new "real" column is created and is asked about the lenght of the filed and the precision is interesting to note that the the lenght includes also the separator between integers and decimals. I don't know if this make sense or not, but it can be confusing at the beginning, at least until a person do realize how it works.
#3
Updated by Tim Sutton over 14 years ago
- Resolution set to invalid
- Status changed from Open to Closed
We believe QGIS is behaving correctly from our tests. For example if you enter 1.12 for the last column QGIS stores the value correctly. Numers greater than or equal to 10 will have their decimal precision truncated to 1 place because the field with is 4 and (10 = 2, . = 1, 1 = 1). i.e the '.' in the number seems to consume one of the allocated places in the number length.
We are closing this bug as invalid as QGIS seems to be behaving according to the constraints of the dbf format.
timlinux@timvaio:/tmp/PUD_STATO_ATTUALE$ dbfdump -h PUD_STATO_ATTUALE.dbf Field 0: Type=String, Title=@COD_ISTAT', Width=6, Decimals=0 Field 1: Type=Integer, Title=@NUM_PROGR', Width=4, Decimals=0 Field 2: Type=String, Title=@TIPO_CONC', Width=8, Decimals=0 Field 3: Type=Integer, Title=@TIPO_ATTIV', Width=2, Decimals=0 Field 4: Type=Integer, Title=@ACCESS_DIS', Width=1, Decimals=0 Field 5: Type=Double, Title=@FRONTE_MAR', Width=4, Decimals=2 COD_ISTAT NUM_PROGR TIPO_CONC TIPO_ATTIV ACCESS_DIS FRONTE_MAR (NULL) (NULL) NUMERO1f 18 2 10.20 (NULL) (NULL) due 11 3 11.30 (NULL) (NULL) NUMERO1f 18 2 10.20 (NULL) (NULL) NUMERO1f 18 2 10.20 Test 12 test 12 1 1.12