Opened 15 years ago

Closed 14 years ago

#2010 closed bug (invalid)

wrong values inserted on the table

Reported by: pcav Owned by: nobody
Priority: critical: causes crash or data corruption Milestone: Version 1.4.0
Component: Data Provider Version: Trunk
Keywords: Cc:
Must Fix for Release: No Platform: All
Platform Version: Awaiting user input: no

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

Attachments (1)

PUD_STATO_ATTUALE.tar.bz2 (1.5 KB ) - added by pcav 15 years ago.

Download all attachments as: .zip

Change History (4)

by pcav, 15 years ago

Attachment: PUD_STATO_ATTUALE.tar.bz2 added

comment:1 by lutra, 15 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

comment:2 by lutra, 15 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.

comment:3 by timlinux, 14 years ago

Resolution: invalid
Status: newclosed

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 
Note: See TracTickets for help on using tickets.