libreoffice version 5.2.2.2 on gentoo-testing When designing query with librebase then average AVG function in query design view, produces a syntax error and one can not run query, save or go to SQL view. A work around is to use MAX function instead, go to SQL view, change by hand the MAX to AVG and save without going to design view again. Using wizard for creating query the AVG function does not produce any errors and query is saved and running successfully. you can see it by opening it directly in SQL. But again if you open the query in design view and try in there the SQL view the problem appears again. Same behavior with libreoffice-4.3.3.2 on debian-jessie the error says something (i translate from greek) Status SQL: HY000 error: 1000 syntax error, unexpected $end, expecting BETWEEN or IN or SQL_TOKEN_LIKE
Which DB do you use? Would you have some example file so we can give it a try?
Have tested with Version: 5.2.3.3 Build-ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf CPU-Threads: 4; BS-Version: Linux 4.1; UI-Render: Standard; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group In a internal HSQLDB I created a query, set AVG by GUI to a numeric field. No problem to run a query. The error, which is reported, is the standard if Base doesn't understand the code. @jimishol: Which *.deb-packages do you use? From LO directly or packages of your distribution?
Created attachment 128557 [details] just for avg testing right click query to edit on sql view so as to see sql code run (f5) to see 2 averages click view on design view try run again or save or leave design view syntax error
i use packages as it comes from my distributions and i used HSQLDB i tried to see if it happens with postgres as well. So on a virtualbox with Arch i installed libreoffice and postgres. Upon query design LO said it needed JRE and i installed jre8-openjdk and problem disappeared!! at HSQLDB too! Now on gentoo i have virtual/jre-1.8.0-r1 and on debian-jessie openjdk-7-jre and default-jre I had no time to test with different jre s and specially on gentoo it isnt easy because of compilation time it will take It seems it is a jre matter
It was not jre matter after all. Sorry. Since I'm Greek I had user interface in greek language. As soon as I choosed from Tools/Options/Language Settings/User interface: English (USA) problem disappeared both on debian and gentoo
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20170531
I can not update right now, may be later. i use Version: 5.2.5.1 Build ID: Gentoo official package CPU Threads: 4; OS Version: Linux 4.6; UI Render: default; VCL: gtk2; Locale: el-GR (el_GR.utf8); Calc: group I installed from gentoo portage I installed app-office/libreoffice-l10n too When i use Greek interface for libreoffice i get this error So i use the default English interface where there is no problem
Put it back to UNCONFIRMED once you test it, otherwise, better to keep it in NEEDINFO
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20180102
Problem fixed by itself at Version: 5.4.4.2 Build ID: Gentoo official package CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; Locale: el-GR (el_GR.utf8); Calc: group Now i can switch to greek interface with no problem I mark as resolved-fixed. Please, put the right tag if it is not the right ones.
I'm deeply sorry. I failed to check properly. On greek interface it continue the same problem when i go to design mode. So i switch back to english interface. I switch to uncorfimed tag, because i have nothing else to add.
No repro with: Version: 5.4.4.2 Build ID: 2524958677847fb3bb44820e40380acbe820f960 Threads CPU : 4; OS : Mac OS X 10.13.2; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group
No repro either with GR langpack : Έκδοση: 5.4.4.2 Αναγνωριστικό δόμησης: 2524958677847fb3bb44820e40380acbe820f960 Νήματα CPU:4; Λειτουργικό σύστημα: Mac OS X 10.13.2; Απόδοση διεπαφής χρήστη: προεπιλογή; Τοπικό: el-GR (fr_FR.UTF-8); Calc: group
@jimishol : 5.2 is no longer current. Given other people's testing without a problem, it appears that your problem is a Gentoo package issue, rather than a problem with a current release of LibreOffice, I am setting this to NOTOURBUG.
I am reopening this bug since I was able to reproduce it on openSUSE Leap 42.3 using 5.4.5.1
(In reply to Markos Chandras from comment #15) > I am reopening this bug since I was able to reproduce it on openSUSE Leap > 42.3 using 5.4.5.1 Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Created attachment 140832 [details] 103736bug-video for average function_on greek translation On updated Arch i installed libreoffice-still-el package
jimishol, Markos: can you try with an appimage of a daily version: https://www.libreoffice.org/download/appimage
I tried appimage. It was full libreoffice-still version 5.4.6.2 Same bug, same behavior. And since i had full version i tried german, italian, french and russian interfaces. None had the greek interface problem.
(In reply to jimishol from comment #19) > I tried appimage. It was full libreoffice-still version 5.4.6.2 > Same bug, same behavior. > And since i had full version i tried german, italian, french and russian > interfaces. None had the greek interface problem. No, please try with the DAILY VERSION.
I tried daily and alpha. Both have only English default interface, so I cann't test the Greek interface. Nevertheless, both crashed when i clicked "edit query" even at english interface.
Right, I forgot about the Greekness along the way. Markos: how were you able to reproduce this? With Greek interface or something else?
(In reply to Buovjaga from comment #22) > Right, I forgot about the Greekness along the way. > Markos: how were you able to reproduce this? With Greek interface or > something else? Yep, I did the exact same thing with jimishol
On pc Debian x86-64 with master sources updated today, I could reproduce this with Greek language.
Created attachment 141180 [details] bt + gdb traces On gdb, I did a ctrl-C when error message box appeared. Then I used: thread apply all bt and finally got this bt Pb is in OQueryController::translateStatement (see https://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/querydesign/querycontroller.cxx#1683)
Lionel: I'm not sure but wonder if the pb may be due to the fact that AVG corresponds to a 2 words "Μέσος όρος" in Greek. Perhaps putting an unbreakable space could make it.
I confirm putting an unbreakable space worked. Lionel: do you think it's ok for the unbreakable space or is it just a workaround and tokenization process should be changed? (I couldn't help for this since I know too little about lex and yacc)
Excuse my interference, I, as simple user for this kind of problems, use visible Shift+"-" as a pointer that space could cause problems. May be it is totally irrelevant but the "Μέσος όρος" appears 4 times at https://opengrok.libreoffice.org/xref/translations/source/el/sc/messages.po
Try putting adding double quotes around "Μέσος όρος"; it that doesn't work, try simple quotes. I don't know if it works, but worth trying. If that doesn't work, yes, put an unbreakable space, a dash "-", an underscore "_" or just remove the space and use CamelCase, whatever the Greek translation community thinks is the least horrible. Thanks
I mean, if you solve the bug at a deeper level and truly allow the process to handle spaces, then all the better. To do that, the right place is probably not the yacc/lex grammar per se. We need to find the code that gets the localised string chosen in the menu and maps it back to SQL keywords (which happen to resemble English). That's the point that needs to be fixed. Hopefully it just needs to treat the whole string gotten from the menu as an indivisible string instead of tokenizing it. To get started on that, look where the error is raised and go from there. If there is already Greek at that point, go back and find where that Greek is coming from. But failing that, at least the non-breaking space will solve this particular bug which is problematic for Greek users.
I tried to play with m_bGraphicalDesign + impl_setViewMode to call getContainer()->switchView just when needed* + revert back the state, I could retrieve "AVG" instead of the localized name. However, when trying trying sql, execute, design, execute, ... I don't remember the order, it still failed at a point. In brief, I can put an unbreakable space in Pootle but can't do more. * 688 case ID_BROWSER_QUERY_EXECUTE: 689 grabFocusFromLimitBox(*this); 690 if ( getContainer()->checkStatement() ) 691 { from dbaccess/source/ui/querydesign/querycontroller.cxx (see https://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/querydesign/querycontroller.cxx#692) Here why I tried this: 68 OUString OQueryViewSwitch::getStatement() 69 { 70 if(m_pTextView->IsVisible()) 71 return m_pTextView->getStatement(); 72 return m_pDesignView->getStatement(); 73 } (gdb) p m_pTextView->IsVisible() $11 = false (gdb) p m_pTextView->getStatement() $12 = "SELECT AVG( \"table-number\".\"number-field\" ) AS \"number-field\" FROM \"table-number\" GROUP BY \"group\"" (gdb) p m_pDesignView->getStatement() $13 = "SELECT Moyenne(\"number-field\") AS \"number-field\" FROM \"table-number\" GROUP BY \"group\" " from (gdb) bt #0 0x00007fffc8193a14 in dbaui::OQueryViewSwitch::getStatement() (this=0x55555895b500) at /home/julien/lo/libreoffice/dbaccess/source/ui/querydesign/QueryViewSwitch.cxx:69 #1 0x00007fffc815c6d9 in dbaui::OQueryContainerWindow::getStatement() (this=0x5555580bd0d0) at /home/julien/lo/libreoffice/dbaccess/source/ui/inc/querycontainerwindow.hxx:82 #2 0x00007fffc8158b69 in dbaui::OQueryController::translateStatement(bool) (this=0x555558e7d650, _bFireStatementChange=false) at /home/julien/lo/libreoffice/dbaccess/source/ui/querydesign/querycontroller.cxx:1686 #3 0x00007fffc81559ac in dbaui::OQueryController::executeQuery() (this=0x555558e7d650) at /home/julien/lo/libreoffice/dbaccess/source/ui/querydesign/querycontroller.cxx:1246 #4 0x00007fffc8152713 in dbaui::OQueryController::Execute(unsigned short, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x555558e7d650, _nId=10721, aArgs=uno::Sequence of length 1 = {...}) at /home/julien/lo/libreoffice/dbaccess/source/ui/querydesign/querycontroller.cxx:690 #5 0x00007fffc7ef54d2 in dbaui::OGenericUnoController::executeChecked(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x555558e7d650, _rCommand=..., aArgs=uno::Sequence of length 1 = {...}) at /home/julien/lo/libreoffice/dbaccess/source/ui/browser/genericcontroller.cxx:1049 I searched about IsVisible and found Show function in OQueryViewSwitch::impl_postViewSwitch itself called from OQueryViewSwitch::switchView
Created attachment 149056 [details] bts I found where the translation was done. I retrieved 7 bts: - 3 when loading query editor (so before typing F5) - 4 after I typed F5 Interestingly, I noticed that in bt4 we got: #0 0x00007ffff3bac2a9 in svxform::OSystemParseContext::getIntlKeywordAscii(connectivity::IParseContext::InternationalKeyCode) const (this=0x555558dbc620, _eKey=connectivity::IParseContext::InternationalKeyCode::Avg) at /home/julien/lo/libreoffice/svx/source/form/ParseContext.cxx:119 #1 0x00007ffff3bac386 in svxform::OSystemParseContext::getIntlKeyCode(rtl::OString const&) const (this=0x555558dbc620, rToken="Μέσος") at /home/julien/lo/libreoffice/svx/source/form/ParseContext.cxx:140 #2 0x00007fffec04b9d0 in connectivity::OSQLScanner::getInternationalTokenID(char const*) const (this=0x5555588aa850, sToken=0x555558766220 "Μέσος") at /home/julien/lo/libreoffice/workdir/LexTarget/connectivity/source/parse/sqlflex.cxx:7309 #3 0x00007fffec04b046 in gatherName(sal_Char const*) (text=0x555558766220 "Μέσος") at /home/julien/lo/libreoffice/workdir/LexTarget/connectivity/source/parse/sqlflex.cxx:7130 #4 0x00007fffec046bd4 in SQLyylex() () at /home/julien/lo/libreoffice/workdir/LexTarget/connectivity/source/parse/sqlflex.cxx:5884 #5 0x00007fffec04ba9b in connectivity::OSQLScanner::SQLlex() () at /home/julien/lo/libreoffice/workdir/LexTarget/connectivity/source/parse/sqlflex.cxx:7322 #6 0x00007fffec040629 in connectivity::OSQLParser::SQLlex() () at /home/julien/lo/libreoffice/workdir/YaccTarget/connectivity/source/parse/sqlbison.cxx:11158 #7 0x00007fffec03dcd1 in SQLyyparse() () at /home/julien/lo/libreoffice/workdir/YaccTarget/connectivity/source/parse/sqlbison.cxx:10339 #8 0x00007fffec03f237 in connectivity::OSQLParser::parseTree(rtl::OUString&, rtl::OUString const&, bool) (this=0x555557b38b80, rErrorMessage="", rStatement="SELECT Μέσος όρος(\"number-field\") AS \"number-field\" FROM \"table-number\" GROUP BY \"group\" ", bInternational=true) at /home/julien/lo/libreoffice/workdir/YaccTarget/connectivity/source/parse/sqlbison.cxx:10921 bt5: #0 0x00007ffff3bac2a9 in svxform::OSystemParseContext::getIntlKeywordAscii(connectivity::IParseContext::InternationalKeyCode) const (this=0x555558dbc620, _eKey=connectivity::IParseContext::InternationalKeyCode::Avg) at /home/julien/lo/libreoffice/svx/source/form/ParseContext.cxx:119 #1 0x00007ffff3bac386 in svxform::OSystemParseContext::getIntlKeyCode(rtl::OString const&) const (this=0x555558dbc620, rToken="όρος") at /home/julien/lo/libreoffice/svx/source/form/ParseContext.cxx:140 #2 0x00007fffec04b9d0 in connectivity::OSQLScanner::getInternationalTokenID(char const*) const (this=0x5555588aa850, sToken=0x555558766220 "όρος") at /home/julien/lo/libreoffice/workdir/LexTarget/connectivity/source/parse/sqlflex.cxx:7309 #3 0x00007fffec04b046 in gatherName(sal_Char const*) (text=0x555558766220 "όρος") at /home/julien/lo/libreoffice/workdir/LexTarget/connectivity/source/parse/sqlflex.cxx:7130 #4 0x00007fffec046bd4 in SQLyylex() () at /home/julien/lo/libreoffice/workdir/LexTarget/connectivity/source/parse/sqlflex.cxx:5884 #5 0x00007fffec04ba9b in connectivity::OSQLScanner::SQLlex() () at /home/julien/lo/libreoffice/workdir/LexTarget/connectivity/source/parse/sqlflex.cxx:7322 #6 0x00007fffec040629 in connectivity::OSQLParser::SQLlex() () at /home/julien/lo/libreoffice/workdir/YaccTarget/connectivity/source/parse/sqlbison.cxx:11158 #7 0x00007fffec03dcd1 in SQLyyparse() () at /home/julien/lo/libreoffice/workdir/YaccTarget/connectivity/source/parse/sqlbison.cxx:10339 #8 0x00007fffec03f237 in connectivity::OSQLParser::parseTree(rtl::OUString&, rtl::OUString const&, bool) (this=0x555557b38b80, rErrorMessage="", rStatement="SELECT Μέσος όρος(\"number-field\") AS \"number-field\" FROM \"table-number\" GROUP BY \"group\" ", bInternational=true) at /home/julien/lo/libreoffice/workdir/YaccTarget/connectivity/source/parse/sqlbison.cxx:10921
In dbaccess/source/ui/querydesign/QueryDesignView.cxx, line 666 from GenerateSelectList method I tried to change this line: OUStringBuffer aTmpStr2( field->GetFunction()); to: OUStringBuffer aTmpStr2(field->GetFunction().replaceAll(OUStringLiteral1(" "), OUStringLiteral1(a0))); to replace plain space by an unbreakable space, still the same result. I'm stuck :-(
Just for the record, I asked some advice from LO devs here: http://document-foundation-mail-archive.969070.n3.nabble.com/Question-about-localized-functions-parsing-in-multiple-words-in-Base-tt4278070.html
Eike's response indicates that even in Calc there shouldn't be a space. Is everyone ok for putting an unbreakable space here?
I changed it for an unbreakable space but it's been changed again by Dimitris Spingos (dmtrs32) to put "AVERAGE". Since I'm not Greek, I don't know what to think. At least, it shouldn't fail so let's put this one to FIXED then.