Description: Report builder fails to switch from step #1 to #2 with certain aggregation queries. Steps to Reproduce: 1.Open the attached database with embedded Firebird. 2. Right-Click query icon "qAggregateV" or "Total_Months" and choose "Report wizard...". 3. In the first step of the wizard click >> to choose all columns and click "Next". Actual Results: The dialog fails to initialize the next step. It does not freeze. It simply stalls. Expected Results: Selected fields are drawn into the document and step #2 (grouping) is initialized. Reproducible: Always User Profile Reset: Yes Additional Info: I don't think, it's the same as #158905 which describes another symptom. I observe this since 24.2. Certain valid queries make the report builder fail. In the attached demo database, two queries "qAggregateV" and "Total_Months" are affected. I have a HSQL version of that database which I tested on Windows and Linux with the same results. "Direct SQL mode" makes no difference. I can manually create working reports from both queries.
Created attachment 194054 [details] Base document with embedded Firebird DB
Reproducible Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7a895ec4205659038aa95941b65715fed1a3e7be CPU threads: 16; OS: Windows 11 (10.0 build 22631); UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded and Version: 7.6.6.3 (X86_64) / LibreOffice Community Build ID: d97b2716a9a4a2ce1391dee1765565ea469b0ae7 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL threaded Last working for me Version: 7.5.9.2 (X86_64) / LibreOffice Community Build ID: cdeefe45c17511d326101eed8008ac4092f278a9 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL threaded
Hi, after pressing 5 times the Next button, next step appear Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba CPU threads: 12; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: it-IT (it_IT); UI: it-IT Calc: CL threaded
(In reply to mc from comment #3) > Hi, after pressing 5 times the Next button, next step appear > > > Version: 24.2.3.2 (X86_64) / LibreOffice Community > Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba > CPU threads: 12; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: > win > Locale: it-IT (it_IT); UI: it-IT > Calc: CL threaded For me, it jumps to the last step without filling any controls into the document.
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2. Adding Cc: to Henry Castro ; Could you possibly take a look at this one? Thanks 482ec9154b07af28171cc9fb83a6577d94b94e66 is the first bad commit commit 482ec9154b07af28171cc9fb83a6577d94b94e66 Author: Jenkins Build User <tdf@pollux.tdf> Date: Fri Sep 1 19:19:40 2023 +0200 source 50f36b75cee6591a00102c6e9fa71ba91df5bbd8 156422: connectivity: fix return column type "DataType::SQLNULL" | https://gerrit.libreoffice.org/c/core/+/156422
Thanks, I will check it
On pc Debian x86-64 with master sources updated today, I could reproduce this. I noticed these on console: warn:bridges:27028:27028:bridges/source/jni_uno/jni_base.h:105: unexpected java exception occurred Exception in thread "Thread-7" warn:bridges:27028:27028:bridges/source/jni_uno/jni_java2uno.cxx:553: Java calling UNO method getPropertyValue: error examining java exception object! warn:toolkit:27028:27028:toolkit/source/helper/listenermultiplexer.cxx:128: ActionListenerMultiplexer::actionPerformed: caught an exception! com.sun.star.uno.RuntimeException message: "[jni_uno bridge error] Java calling UNO method getPropertyValue: error examining java exception object! java stack trace: com.sun.star.uno.RuntimeException: [jni_uno bridge error] Java calling UNO method getPropertyValue: error examining java exception object! at com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(Native Method) at com.sun.star.bridges.jni_uno.JNI_proxy.invoke(JNI_proxy.java:185) at jdk.proxy1/jdk.proxy1.$Proxy13.getPropertyValue(Unknown Source) at com.sun.star.wizards.db.FieldColumn.initializeFormatKeys(FieldColumn.java:154) at com.sun.star.wizards.db.FieldColumn.getFieldType(FieldColumn.java:96) at com.sun.star.wizards.db.FieldColumn.getTyperelatedFieldData(FieldColumn.java:216) at com.sun.star.wizards.db.FieldColumn.initializeFormatKeys(FieldColumn.java:155) at com.sun.star.wizards.db.FieldColumn.getFieldType(FieldColumn.java:96) at com.sun.star.wizards.db.FieldColumn.getTyperelatedFieldData(FieldColumn.java:216) at com.sun.star.wizards.db.FieldColumn.initializeFormatKeys(FieldColumn.java:155) at com.sun.star.wizards.db.FieldColumn.getFieldType(FieldColumn.java:96) at com.sun.star.wizards.db.FieldColumn.getTyperelatedFieldData(FieldColumn.java:216) at com.sun.star.wizards.db.FieldColumn.initializeFormatKeys(FieldColumn.java:155) at com.sun.star.wizards.db.FieldColumn.getFieldType(FieldColumn.java:96) etc. In initializeFormatKeys method in FieldColumn.java, LO goes until 155 getTyperelatedFieldData(); (see https://opengrok.libreoffice.org/xref/core/wizards/com/sun/star/wizards/db/FieldColumn.java?r=510b9557#155) in getTyperelatedFieldData, we got: 211 private void getTyperelatedFieldData() 212 { 213 int StandardFormatKey = 0; 214 try 215 { 216 switch ( getFieldType() ) so getFieldType() is called, we got there: 91 public int getFieldType() 92 { 93 if (m_nFieldType == 0) 94 { 95 DBMetaData.CommandObject oTable = m_aCommandMetaData.getTableByName(m_sCommandName); 96 initializeFormatKeys(m_aCommandMetaData, oTable.getColumns()); 97 } 98 return m_nFieldType; 99 } but since m_nFieldType is equal to 0, LO goes to the line 96 and we enter a never ending loop. m_nFieldType is equal to 0 after Henry's patch but I don't think his patch is the pb, I rather think it revealed a pb. Indeed the patch changed by default return value of "getFunctionReturnType" from DataType::VARCHAR (value 12) to DataType::SQLNULL (value 0) But, it's just a default value and when giving a try on Gdb, I noticed that when the function was called with "_sFunctionName" = "AVG", LO doesn't go into this line: else if(sFunctionName.equalsIgnoreAsciiCase(TokenIDToStr(SQL_TOKEN_AVG,pContext))) nType = DataType::DOUBLE; (see https://opengrok.libreoffice.org/xref/core/connectivity/source/parse/sqlnode.cxx?r=aa80eaee#2578) That's because TokenIDToStr(SQL_TOKEN_AVG,pContext) returns "Average" not "AVG". Indeed TokenIDToStr relies on RID_RSC_SQL_INTERNATIONAL 38 NC_("RID_RSC_SQL_INTERNATIONAL", "Average"), see https://opengrok.libreoffice.org/xref/core/svx/inc/fmstring.hrc?r=dcea29c2#38 So this change: diff --git a/svx/inc/fmstring.hrc b/svx/inc/fmstring.hrc index d630f354b879..4b0c7005f3f0 100644 --- a/svx/inc/fmstring.hrc +++ b/svx/inc/fmstring.hrc @@ -35,7 +35,7 @@ const TranslateId RID_RSC_SQL_INTERNATIONAL[] = NC_("RID_RSC_SQL_INTERNATIONAL", "BETWEEN"), NC_("RID_RSC_SQL_INTERNATIONAL", "OR"), NC_("RID_RSC_SQL_INTERNATIONAL", "AND"), - NC_("RID_RSC_SQL_INTERNATIONAL", "Average"), + NC_("RID_RSC_SQL_INTERNATIONAL", "AVG"), NC_("RID_RSC_SQL_INTERNATIONAL", "Count"), NC_("RID_RSC_SQL_INTERNATIONAL", "Maximum"), NC_("RID_RSC_SQL_INTERNATIONAL", "Minimum"), allows to return DataType::DOUBLE (value 8) instead of 0 for "AVG" keyword and the bug can't be reproduced. Does it seem ok to you?
Either my conclusion in my previous comment is wrong or MIN and MAX have the same pb knowing that svx/inc/fmstring.hrc contains "Minimum" and "Maximum".
Hi, Sorry I was busy other tasks, I will resolve the issue exclusively this week, thanks for the additional info =). In progress ...
Thanks Julien, I have tested your patch and it works, your conclusion is correct. - NC_("RID_RSC_SQL_INTERNATIONAL", "Average"), + NC_("RID_RSC_SQL_INTERNATIONAL", "AVG"), Can you please create the patch to mark as resolved?
(In reply to Henry Castro from comment #10) > ... > Can you please create the patch to mark as resolved? Thank you for the feedback, patch done here: https://gerrit.libreoffice.org/c/core/+/173186
(In reply to Julien Nabet from comment #8) > Either my conclusion in my previous comment is wrong or MIN and MAX have the > same pb knowing that svx/inc/fmstring.hrc contains "Minimum" and "Maximum". MIN and MAX are dealt specifically, 2050 // MIN and MAX have another return type, we have to check the expression itself. 2051 // @see http://qa.openoffice.org/issues/show_bug.cgi?id=99566 2052 if ( SQL_ISRULE(_pNode,general_set_fct) && (SQL_ISTOKEN(_pNode->getChild(0),MIN) || SQL_ISTOKEN(_pNode->getChild(0),MAX) )) See https://opengrok.libreoffice.org/xref/core/connectivity/source/parse/sqliterator.cxx?r=7f5a7ef6#2050
>> MIN and MAX are dealt specifically, Indeed you are right, we should change it. But someone should provide a test document to verify it.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a42270bb4d56a538333aa317cb6425a95c37bb8c tdf#161007: Report Builder Wizard fails It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Henry Castro from comment #13) > >> MIN and MAX are dealt specifically, > > Indeed you are right, we should change it. But someone should provide a test > document to verify it. I mean I was wrong in my first comment about MIN and MAX, I don't think MIN and MAX treatment should be modified. Indeed, MIN and MAX need a special treatment since they can deal DOUBLE but also DATE, TIME, etc. and LO already deals all this. Concerning AVG again, before cherry-picking the patch from master towards 24.8 and/or 24.2, it would be great to have some feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/f8ca789be3f5f3f7948eb54cefefe8aa552e2cd3 tdf#161007: Report Builder Wizard fails It will be available in 24.8.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/2bcd870fc526048e7968c16b6411d596ef724faa tdf#161007: Report Builder Wizard fails It will be available in 24.2.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco cherry-picked the patch, hope he's sure it's ok! :-) Let's put this one to FIXED.