Bug 117333 - FIREBIRD: Migration: After first SQL-error nothing else will be imported
Summary: FIREBIRD: Migration: After first SQL-error nothing else will be imported
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected)
Hardware: x86-64 (AMD64) All
: highest critical
Assignee: Not Assigned
Whiteboard: target:6.1.0
Keywords: haveBacktrace
Depends on:
Blocks: Database-Firebird-Migration
  Show dependency treegraph
Reported: 2018-04-29 15:33 UTC by Robert Großkopf
Modified: 2018-05-17 19:17 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Tra to migrate the attached database - only 7 tables without content, but different field-types. (4.05 KB, application/vnd.oasis.opendocument.database)
2018-04-29 15:33 UTC, Robert Großkopf
bt with debug symbols (11.63 KB, text/plain)
2018-05-13 17:37 UTC, Julien Nabet
test file (3.19 KB, application/vnd.oasis.opendocument.database)
2018-05-17 19:17 UTC, Drew Jensen

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2018-04-29 15:33:24 UTC
Created attachment 141757 [details]
Tra to migrate the attached database - only 7 tables without content, but different field-types.

Download the attached database.
Open the file - contains 7 tables with fields and different datatypes.
Now execute the migration.
Migration ends with an error - no really usable information about the background for the error.
No tables are available.
Save the file.
Reopen the file.
One table ("tabTimeDate") is available. All other tables are lost.

Expected behavior: Only one table is lost, because there is only one error-message.

With this migration-behavior it seems to be very tricky to find the reason for a failing migration. Couldn't be there are fields in all the 6 tables, which couldn't be imported.
Comment 1 Alex Thurgood 2018-05-04 08:07:28 UTC
Confirming with

Build ID: f5a56c367fba1c42b4f9719b10ff3e86ad5e2ab1
CPU threads: 4; OS: Mac OS X 10.13.4; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group

This is my daily build from yesterday evening.
Comment 2 Julien Nabet 2018-05-13 17:37:54 UTC
Created attachment 142080 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today + enable-dbgutil, I got an assert.
Here are the main lines of bt:
#4  0x00007fffc9e8845c in (anonymous namespace)::lcl_getDataTypeFromHsql(rtl::OUString const&) (sTypeName="OBJECT")
    at /home/julien/lo/libreoffice/dbaccess/source/filter/hsqldb/createparser.cxx:140
#5  0x00007fffc9e88893 in dbahsql::CreateStmtParser::parseColumnPart(rtl::OUString const&) (this=0x7fffffff0710, sColumnPart="\"ID\" INTEGER NOT NULL PRIMARY KEY,\"JaNein\" BOOLEAN,\"Binary_fix\" BINARY,\"BinVar\" VARBINARY,\"BildLongVar\" LONGVARBINARY,\"Other\" OBJECT")
    at /home/julien/lo/libreoffice/dbaccess/source/filter/hsqldb/createparser.cxx:191

I attached the whole bt.
Comment 3 Commit Notification 2018-05-16 09:11:40 UTC
Tamas Bunth committed a patch related to this issue.
It has been pushed to "master":


tdf#117333, tdf#117325 dbahsql: exception handling

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.
Comment 4 Drew Jensen 2018-05-17 19:17:09 UTC
Created attachment 142171 [details]
test file

Again, the original file no longer generates an error and all 7 tables are imported.

So, test this with: 
Build ID: 47dc3115f12ff16dc326b6edd12c46e6a6ef1843
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-05-17_00:32:17
Locale: en-US (en_US.UTF-8); Calc: group

Using this new test file.
Migration begins.
Table1 generates an error (due to a current bug)
User dismissed the error box.
Migration continues and Table2 is successfully imported.