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
Created attachment 178262 [details] Test database Firebird embedded
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
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
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.
Same behavior in LO 6.4.7.2. Could be it is an old bug.
Same behaviour LO 7.3.0.3 in windows