Description: basically this comes down to how assertive the migration process should be. If you look at the attached screen shot you see that the migration functionality is started from the Mail Merge Wizard if any hsql based odb is open to DISPLAY the tables in side. I wanted this database for the mail merge and I said go ahead and migrate it. In fact I really only ever use this file from Mail Merge. The migration function executed without error and I could run my mailmerge. I closed the file. // time passes I start a new mail merge document, want the same database. The migration process is triggered. The migrated ODB was not saved, when I closed out the mail merge process it quietly closed the ODB also. (NOTE, if the migration function has any error then another bug is triggered and the ODB can not be used for anything until LibO session is ended and restarted) Steps to Reproduce: 1. Open/Create a writer file. 2. Start the mail merge wizard 3. IF the last registered database used for a mail merge is an HSQL:sdbc file the auto migration prompts happens here 3. OTHERWISE In step three select 'Select Adress List' 4. click on any HSQL:sdbc based databse on the list presented and the migration function prompt displays when the list control prepares to show available tables. 5. However you got here: Select Yes. Actual Results: Changes to ODB from auto migration triggered from beamer window and mail merge ( and possibly other vectors ) offer no way for the user to save the ODB file after success. Expected Results: Changes are permanent. Reproducible: Always User Profile Reset: No Additional Info: Optionally, could be a RFE 'Be less assertive and check for use cases not to prompt for auo-migration as part of functionality'. User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/65.0.3325.181 Chrome/65.0.3325.181 Safari/537.36
Created attachment 142003 [details] screen shot
Could confirm mail-merge wizard doesn't offer any possibility to save the data, which are migrated from internal HSQLDB to internal Firebird database. Tested with Version: 6.1.0.0.alpha1+ Build-ID: ecf50fe71596c3edba8ce437481ab80ae1cd8935 CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: kde4; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-05-08_00:13:13 Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
Ouch ! Similar to the other Beamer bug already referenced in BZ. Needs a solution.
What about not asking the users to migrate it from Beamer and it can only be done if the database is open in Base?
Having it only ask if the Base window is open and visible would be a solution. When an embedded database is in use the Base file is always opened, by definition, but sometimes not in a visible state. The beamer, built in mail merge wizard are two examples of when it is opened but not visible. There are at least two published extensions, on the libo and AOO extension services, which do the same. That old base extension which I put to the nextcloud the other day (and rambled on about on irc) it hides the base window then launches a report, with the migration assistant pop up triggered, and the results of saying yes are just as problematic because the extension code doesn't realize it needs to save the file when it is done.
Actually I am almost certain that in cases of basic scripts which hide the base window, for whatever reason, it can be more problematic still because of how basic handles event processing. The main reason I dug up that old extension was to try it against hsql files and say yes to the migration assistant, particularly hsql files which trigger error messages, and check how that interplay with the basic engine goes. I've run a couple of tests and it gets a little odd. I haven't pestered with opening an issue because, to be honest, the assistant isn't even moving data properly, yet, for every data type, and I don't care about the rest so much until at least that is happening. With no word (and no code check ins) from Tamas for over almost 2 weeks, and assuming that the data integrity during migration is the prime concern, I figured that meant he was still head down working on that core stuff.
Fixed by https://gerrit.libreoffice.org/plugins/gitiles/core/+/77ef0a92b3bd19f836d0fcb2a41af5e643129283%5E%21