Created attachment 150833 [details] Test ODB file Platform Ubuntu 18.04 with Version: 6.3.0.0.alpha0+ Build ID: aabafa92a5d66a9d706125b88bfca55fd3ca6473 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-04-10_08:08:46 Locale: en-US (en_US.UTF-8); UI-Language: en-US Also ran this scenario of actions using LO 6.2.2 and there is no problem with the original ODB file afterwards. Marked as regression therefore. Additionally, running migration assistant against the test file without this earlier set of steps in 6.3, on first open of the ODB in other words, runs just fine with the data migrated as expected. Steps to reproduce 1 Open any odb file with embedded HSQL (download attached file for simplest case) 2 Select the data section to connect to the data, do not begin a migration when prompted. 3 Create a backup of the opened file by selecting File->Save As, alter the name appropriately and click Save. 4 The Migrate Wizard dialog opens again, against the newly saved file. This time select Begin migration. 5 The migration assistant finishes immediately (too fast), there are no error messages. 6 Click on the data section of the file. Error 1 - no tables are found. 7 Close the open ODB file and do not save changes. 8 Exit soffice and restart it. 9 Open the original file again, not the one you created in step 3 above, and open the data section. Error 2 - The table are gone. (tried a few with multiple table and views, empty in those also) You now have two ODB files on disc 1 with an HSQL sdbc and one with Firebird sbdc and both with empty data bases.
Setting this to new since I can duplicate it using the 6.3 bibsect repository files, with some iterations passing and some failing. bibisect reported arrival of the anomaly with: commit 306758ab3e06f7c730bb1625c2f3fcce7a912fa3 (patch) tdf#117066 Saving ODT document with ~1500 bookmarks is slow, part 5 OStorageImpl is spending time iterating over its m_aChildrenVector to find stuff by name, so just use a std::unordered_map. Also return iterator from FindElement, so we can avoid searching the map twice. -rw-r--r-- package/source/xstor/xstorage.cxx 169 -rw-r--r-- package/source/xstor/xstorage.hxx 7
Created attachment 150841 [details] the original HSQL ODB file after the seccnario Attaching the original ODB file, the one that should not of been updated at all, as it is when the scenario is finished. What is missing is the data file under the database directory.
No repro with the following version of master on macOS: Version: 6.3.0.0.alpha0+ Build ID: ce2b98580b9f36d6f358bd2c9c027d3d82cb33d7 CPU threads: 8; OS: Mac OS X 10.14.3; UI render: default; VCL: osx; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2019-01-30_01:04:02 Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded which I'm guessing is older than the commit you reference.
Confirming with daily : Version: 6.3.0.0.alpha0+ Build ID: ea9c13be02ba731074fa4207944ff7df40a0fb5c CPU threads: 8; OS: Mac OS X 10.14.3; UI render: default; VCL: osx; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2019-04-10_20:43:17 Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded
*** This bug has been marked as a duplicate of bug 125339 ***
not a firebird migration problem but a base problem...