Bug 164465 - Error in Date control of Base form when executing a macro. Control shows 31-12-2200 or 01-01-1800 when clicking on every value of calendar.
Summary: Error in Date control of Base form when executing a macro. Control shows 31-1...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
25.2.0.0 alpha0+
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks: Macro-StarBasic
  Show dependency treegraph
 
Reported: 2024-12-26 08:52 UTC by Emiliano A. González
Modified: 2024-12-29 07:27 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Database (600.54 KB, application/vnd.oasis.opendocument.database)
2024-12-26 08:52 UTC, Emiliano A. González
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Emiliano A. González 2024-12-26 08:52:35 UTC
Created attachment 198265 [details]
Database

An error occurred in a Base form when executing a macro.
This macro is not new. I have been using it since OpenOffice, quite a few years. It has never shown an error before.
LibreOffice Base Firebird.
When running in LibreOffice 25.2 RC1 the following comes up:

Error de ejecución de BASIC.
Se ha producido una excepción
Type: com.sun.star.sdbc.SQLException
Message: firebird_sdbc error:
*value exceeds the range for valid dates
caused by
'isc_dsql_execute'

Macro:

Sub ActualizarFechaAnterior( Event )

   obj = Event.Source.Model
   fecha_seleccionada = obj.Text
   fecha_anterior = DateAdd("d", -1, fecha_seleccionada)
   frm = obj.Parent
   obj_fecha_seleccionada = frm.getByName("fecha_inicial")
   obj_fecha_seleccionada.BoundField.UpdateString(Format(fecha_seleccionada,"YYYY-MM-DD"))
   obj_fecha_anterior = frm.getByName("fecha_anterior")
   obj_fecha_anterior.BoundField.UpdateString(Format(fecha_anterior,"YYYY-MM-DD"))
   frm.UpdateRow

End Sub

Version: 25.2.0.1 (X86_64) / LibreOffice Community
Build ID: ddb2a7ea3a8857aae619555f1a8743e430e146c9
CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: kf5 (cairo+wayland)
Locale: es-ES (es_ES.UTF-8); UI: es-ES
Sistema operativo: Fedora Linux 41
Versión de KDE Plasma: 6.2.4
Versión de KDE Frameworks: 6.9.0
Versión de Qt: 6.8.1
Versión del kernel: 6.12.6-200.fc41.x86_64 (64 bits)

Form: "Informes"
Control: "Fecha de Inicio"
Action: "when changing date"
Comment 1 zcrhonek 2024-12-27 08:48:08 UTC
I cannot reproduce the bug, tested with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: cac9c7db6257b27724d90d4a355e52e456ef7e08
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded

my steps:
open form Informes
change date in Fecha de inicio

Are the steps correct?
Comment 2 Emiliano A. González 2024-12-27 19:20:44 UTC
The bug is in version 25.2.0.1 (X86_64) / LibreOffice Community.
In the header it appears 25.2.0.0 alpha0+ because when the bug was released it is the highest one that appears in the form.
There were no options for Betas or for this RC1.
Emiliano González
Comment 3 Robert Großkopf 2024-12-28 11:00:49 UTC
When opening 
Form: "Informes"
Control: "Fecha de Inicio"
Action: "when changing date"

and trying to set the date by opening calendar the content of the date control switches to
31.12.2200
which is the maximum value of the date-control.
But: Maximum for date in Firebird is 31-12-9999, so it shouldn't be the problem for Firebird. Seems a totally wrong date should be submitted.

Tested with other database: Won't show the same behavior of a date control. Could be it is a special effect of the macro code.

Bug won't appear in LO 24.8.4.2. So it's a regression.

Version: 25.2.0.1 (X86_64) / LibreOffice Community
Build ID: ddb2a7ea3a8857aae619555f1a8743e430e146c9
CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded
Comment 4 jcsanz 2024-12-28 18:11:18 UTC
In my test the macro is working well, that is, the date in the "fecha_anterior" control is updated to the selected date - 1 (the selected date in the calendar), but the "fecha_inicial" control don't show the selected date but always shows 01/01/1800, don't mind what was the date selected in the calendar.

---------------------
Version: 25.2.0.1.0+ (X86_64) / LibreOffice Community
Build ID: 8627038f93cb0666eb8eaaf657ae5db145416033
CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded
Comment 5 Emiliano A. González 2024-12-28 18:55:14 UTC
With v. 25.2.0.1 (X86_64) / LibreOffice Community,formatting the table “parametros” Edit Date [DATE] Date field format: dd/mm/yyyy does not cause macro execution error, but “fecha inicio” 01/01/1800.

The problem is that the versions, up to 24.8, all, once the tables are formatted, with the fields in their different formats, alignments, field size, and views, for example, numeric 1,247.68, date dd/mm/yyyy, and save them, close the base. In the next opening it deletes everything and only shows numeric 1247,68 or numeric dd/mm/yyyy.

In 25.2.0.1 it keeps some formats, and in several tables.
There must have been some change in the code that shows the table display, hence the macro error when the date in parameters appears as dd/mm/yy.

When it is in dd/mm/yyyy format, the macro is executed correctly changing "fecha anterior" correctly, but start date is changed“fecha inicio” to 01/01/1800.

Version: 25.2.0.1 (X86_64) / LibreOffice Community
Build ID: ddb2a7ea3a8857aae619555f1a8743e430e146c9
CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: kf5 (cairo+wayland)
Locale: es-ES (es_ES.UTF-8); UI: es-ES
Sistema operativo: Fedora Linux 41
Comment 6 Robert Großkopf 2024-12-29 07:26:46 UTC
Reason for the bug is the date control, which won't work. It will save the right value in LO 24.8.4.2, fails to save the choosen value in LO 25.2.0.1