Created attachment 153015 [details] Example database for testing Take an *.odb-file as the attached file. Try to create a view of the query "View_Bericht_Ware_gruppiert". There isn't any possibility to create the view through the contextmenue of the query. This will work up to LO 6.2, fails since LO 6.3: Open any query of the database to edit. Close the query - there must nothing be changed, nothing be saved. Now have a look at the contextmenue of the query. "Create as View" will be available.
Created attachment 153016 [details] Screenshots of contextmenue before and after editing query
Confirmed with Version: 6.4.0.0.alpha0+ Build ID: 4fe32e65cc56cec959af811a9a99348e764e4966 CPU threads: 4; OS: Mac OS X 10.14.5; UI render: default; VCL: osx; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded
Hi Robert, Are you sure this is a regression? I can reproduce it back to Version: 5.2.0.0.alpha1+ Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; Locale: ca-ES (ca_ES.UTF-8) Please make sure you click directly on Views - Right click on the view. If I click on tables and the on views, the menu option is displayed.
(In reply to Xisco Faulí from comment #3) > Hi Robert, > Are you sure this is a regression? I haven't set the keyword "regression", because I have the same behaviour in every installed LO-version here. I will delete "regression" - hope Alex could confirm. Have tested with LO 5.1.5.2 - Create as View will only appear after opening the query for editing and close it without changing anything. Could be the bug is inherited from OOo, but haven't installed earlier versions. Have installed AOO 4.1.6. Behaviour is the same there. I notice this: I must only execute the query and "Create as View" is there. I must only go to "Tables" first and "Create as View" is there. Seems the entry appears only after the connection to the database will be established. Expected behaviour is: The entry must be there and when I click on the entry the connection to the database will be established, if there hasn't be a connection. There should appear no entry when the database doesn't allow to create views.
Does it happen with Firebird only or with HSQLDB as well ? I think we can lower the severity/priority
Testing for me on macOS 10.14.5 using a hsqldb test file with LO versions earlier than 5.1 causes systematic crashing so its a bit difficult to be categorical. This is not linked to the present reported bug, but seemingly either the bit version, or Java recognition, or a combination of both. It makes testing for the origin of this kind of bug impossible on macOS. Anyway, when I can open an ODB file that doesn't cause LO to crash, I can confirm Robert's findings that the menu entry only seems to appear after either the record set is fetched, or the metadata is fetched, (via Tables and right-mouse-button clicking on a table) or else editing a query in the SQL Query editor (which I guess does something similar). From what I can tell, it is independent of the type of DB engine.
My guess is that GetMetaData() is not called systematically, which in turn means the ability or not of the DB engine to support a view, which causes the menu entry to be inserted in the menu, is indeterminate until such time as the metadata is called and analyzed. Or, alternatively, it is called, but incorrectly analyzed, or something blocks that determination for a period of time, leading to the strange delayed display behaviour. Maybe even some SlotID confusion somewhere in the menu entry population ? It would require debugging to see where things go wrong.
On pc Debian x86-64 with master sources updated today, I could reproduce this. After some debugging, the pb is in: https://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/app/AppController.cxx?r=7e403195#817 808 case SID_DB_APP_CONVERTTOVIEW: 809 aReturn.bEnabled = !isDataSourceReadOnly(); 810 if ( aReturn.bEnabled ) 811 { 812 ElementType eType = getContainer()->getElementType(); 813 aReturn.bEnabled = eType == E_QUERY && getContainer()->getSelectionCount() > 0; 814 if ( aReturn.bEnabled ) 815 { 816 Reference<XViewsSupplier> xViewSup( getConnection(), UNO_QUERY ); 817 aReturn.bEnabled = xViewSup.is() && Reference<XAppend>(xViewSup->getViews(),UNO_QUERY).is(); 818 } 819 } line 817 xViewSup.is() returns false since we haven't called "ensureConnection" yet. Opening a query or just going to Tables pane calls "ensureConnection", that's why "Create as View" is available then.
Lionel: I submitted a patch here https://gerrit.libreoffice.org/c/core/+/88329 as you may have seen. If Jenkins is ok, I'll push this. Don't hesitate to comment if the patch is wrong.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/57a5c0f04526fc05907334311db5727e665bdde2 tdf#126578: call ensureConnection to be able to call "Create as View" It will be available in 7.0.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.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/e4e8e8038b06adef9e0abc743b7cc85cc39279cd tdf#126578: call ensureConnection to be able to call "Create as View" It will be available in 6.4.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.