Created attachment 141306 [details]
test odb (hsql embedded data w/ defined relationship)
Open attached odb file (created w/Libo6.0.4, embedded hsql, 2 tables and 1 relationship) using Libo6.1
Select tables. (database is migrated to firebird)
Select Tools->Relations. The relationship editor still displays the two table objects (Products and Suppliers) but the 1-N relationship (Products.SupplierID, Suppliers.SupplierID) is lost.
Could confirm the buggy behavior.
When starting the database under
CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: kde4;
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-04-10_23:32:35
I get this error:
*unsuccessful metadata update
*CREATE TABLE Products failed
*Table Products already exists
'CREATE TABLE "Products" ( "LeadTime" VARCHAR(50), "ProductID" INTEGER NOT NULL PRIMARY KEY, "UnitPrice" DECIMAL(17), "CategoryID" INTEGER, "SupplierID" INTEGER, "ProductName" VARCHAR(50), "Discontinued" BOOLEAN, "ReorderLevel" INTEGER, "Serialnumber" VARCHAR(50), "UnitsInStock" INTEGER, "UnitsOnOrder" INTEGER, "ProductDescription" VARCHAR(250))'
... but the tables appear, when switching to the "Tables"-section.
Then I opened the relationship and see two tables without any connection. Seems the GUI has recognized there are two tables for the relationship, but doesn't know the relation. Created the relation, saved and closed the database - reopened and the relation has gone again. I have to close the database after the migration and have to reopen it again. Then I could create the relation without loosing it.
Tamas Bunth committed a patch related to this issue.
It has been pushed to "master":
tdf#116965 dbahsql: migrate relationgships
It will be available in 6.1.0.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
The migration routine does move relationships.
The test file I uploaded originally is a bad example, as it is one of those with a errant firebird.gbk in it (still not sure how all the ways are to get that to happen) and that generates problems with migration.
So - I'll attach the clean file used to verify this.
4 tables, fk relations for same, 1 view and 1 query, all migrate.
Created attachment 141455 [details]
clean test file used to verify relationship migration