Description: As per summary. Steps to Reproduce: (0) Ensure that you have enabled experimental features in LibreOffice. (Tools > Options... > LibreOfficeDev > Advanced > "Optional Features" > "Enable experimental features (may be unstable)") (1) Download and open the (soon-to-be) attached a02.odb. Program presents the main database window. (2) In the main database window, take menu options Tools > Relationships... . The program presents window Relationship Design. Observe Table1 and Table2 in the main area of the window. (3) In Relationship Design window, Drag Table1.f2 and drop it on Table2.f2. There is no visible result. (Bug 45257 complains about the lack of a line between the two tables.) (4) In Relationship Design window, take menu options File > Save. (5) In Relationship Design window, take menu options File > Close. Program closes Relationship Design window and returns focus to the main database window. (6) In the main database window, take menu options Tools > Relationships... . Observe line between Table1 and Table2 in the Relationship Design window. (7) In the Relationship Design window, Right-click on the line between Table1 and Table2. Program presents a pop-up menu. (8) From pop-up menu, select Delete. Actual Results: Error dialog ... firebird_sdbc error: *Dynamic SQL Error *SQL error code = -104 *Name longer than database column size caused by 'isc_dsql_prepare' Expected Results: Focus returns to Relationship Design window, which now has no line joining the two tables. Reproducible: Always User Profile Reset: Yes Additional Info: These observations are from debian-stretch and daily Linux dbutil bibisect repository version 2017-04-15. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Created attachment 132596 [details] example .odb with embedded Firebird
On pc Debian x86-64 with master sources updated today, I could reproduce this.
It seems Firebird needs more sanitizing, here some console logs: TODO ODatabaseMetaData::getImportedKeys PK table= 'Table2 ' TODO ODatabaseMetaData::getImportedKeys PK column= 'f2 ' TODO ODatabaseMetaData::getImportedKeys FK table= 'Table1 ' TODO ODatabaseMetaData::getImportedKeys FK column= 'f2 ' Information need trimming there but I think that any getString would need it.
I gave a try with https://gerrit.libreoffice.org/#/c/36642/ Lionel/Tamás: as you may have noticed, I put you in cc for the patch. I noticed too this: " /** * Make sure an identifier is safe to use within the database. Currently * firebird seems to return identifiers with 93 character (instead of * 31), whereby the name is simply padded with trailing whitespace. * This removes all trailing whitespace (i.e. if necessary so that * the length is below 31 characters). Firebird automatically compensates * for such shorter strings, however any trailing padding makes the gui * editing of such names harder, hence we remove all trailing whitespace. */ " see http://opengrok.libreoffice.org/xref/core/connectivity/source/drivers /firebird/Util.hxx#36 I don't know if it's still relevant with last stable Firebird version.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d499cb3bd585e9fcc21bc586cad3d2ad2487a451 tdf#107196: fix firebird relationship It will be available in 5.4.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: http://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-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dfb7ee83299606f7c46bc175bc47710ee887009c&h=libreoffice-5-3 tdf#107196: fix firebird relationship It will be available in 5.3.4. 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Let's put this one to FIXED since I don't think it worths it to backport in 5.2 branch.
Thank you, Julien, for the fix. The error message upon deletion of the relationship goes away between daily Linux dbgutil bibisect repository versions 2017-05-03 and 2017-05-04. However, the latter version seems not to delete the relationship at all: the line representing the relationship survives the deletion, survives closing and reopening Database Relations, and survives closing and reopening the .odb. Would you like to deem the enduring relationship to be part of the original problem, or shall I file a new bug report?
On your file, it seems the relation has been put several times. Indeed, you must delete it about 5 or 6 times (maximum 10) to really remove it. For the test, you can also create a brand new file and give a try.
Ah yes, Julian. I remember that I was working around bug 45257, and I kept adding relationships until the window showed the line. I am setting status VERIFIED FIXED. Again, thank you, Julian.