Bug 147408

Summary: EDIT Integer out of range overflows without message
Product: LibreOffice Reporter: jcsanz
Component: BaseAssignee: Not Assigned <libreoffice-bugs>
Status: NEW ---    
Severity: normal CC: bugzilla, buzea.bogdan, gmolleda, robert
Priority: medium    
Version: 6.4.7.2 release   
Hardware: All   
OS: All   
Whiteboard:
Crash report or crash signature: Regression By:
Bug Depends on:    
Bug Blocks: 108441    
Attachments: Test database Firebird embedded

Description jcsanz 2022-02-14 10:26:23 UTC 
Description:
When inserting an integer greater than the allowed range in a table, an overflow occurs and the number is modified without displaying any message to the user. That is, if in a SMALLINT we try to enter a positive number greater than 32767, for example 33000, it becomes -32536 and does not warn the user.

However, if you try to do the insertion directly, for example with the statement INSERT INTO "NUMS" (NUM) VALUES (33000), the database engine raises an exception and shows a message to the user




Steps to Reproduce:
1. Create a table with a SMALLINT field or use the attached table
2. Open the table to enter data
3. Enter in the SMALLINT field a value out of range, e.g. 33000.
4. When you save the changes, the number becomes a different one, in case of entering 33000 it becomes -32536.

To check that it is a problem of how Base handles the data, and not of the underlying engine:
5. In the main menu select Tools > SQL
6. Execute the INSERT INTO "NUMS" (NUM) VALUES (33000) statement, or a similar one adjusted to your field and table names.
7. You will receive a message that the data cannot be inserted.

Actual Results:
-32536 (a different number from the one inserted)

Expected Results:
A message warning about the invalidity of the data.


Reproducible: Always


User Profile Reset: No



Additional Info:
Tested wit Firebird embedded, HSQLDB embedded, Firebird external file, and MariaDB server 

Version: 7.3.0.3 (x64) / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL
Comment 1 jcsanz 2022-02-14 10:30:34 UTC 
Created attachment 178262 [details]
Test database Firebird embedded
Comment 2 elmau 2022-02-14 13:36:15 UTC 
Confirmed it with:

Postgres 13 and

Version: 7.3.0.3 / LibreOffice Community
Build ID: 30(Build:3)
CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
7.3.0-4
Calc: threaded
Comment 3 jcsanz 2022-02-15 16:46:46 UTC 
The problem also occurs with the NUMERIC and DECIMAL data types, although for these it is more difficult to check the overflow because the SQL implementation guarantees at least the selected size, but may not limit the maximum size
Comment 4 Robert Großkopf 2022-02-17 21:08:58 UTC 
Could confirm with internal Firebird, PostgreSQL direct connection, internal HSQLDB …

All tested with LO 7.3.1.1 on OpenSUSE 15.3 64bit rpm Linux.
Comment 5 Robert Großkopf 2022-02-17 21:11:02 UTC 
Same behavior in LO 6.4.7.2. Could be it is an old bug.
Comment 6 Longi 2022-02-18 06:27:05 UTC 
Same behaviour 
LO 7.3.0.3 in windows