Bug report #2010

wrong values inserted on the table

Added by Paolo Cavallini over 14 years ago. Updated over 14 years ago.

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


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.

PUD_STATO_ATTUALE.tar.bz2 (1.46 KB) Paolo Cavallini, 2009-10-14 08:58 AM


#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
(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 

Also available in: Atom PDF