[Libreoffice-bugs] [Bug 117446] Firebird: Migration: LibO hangs with data type Binary[ VARBINARY] OR Binary(fix)[BINARY] AND data in hsql database over 8000 bytes

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=117446

Drew Jensen <drewjensen.inbox at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Firebird: Migration: LibO   |Firebird: Migration: LibO
                   |hangs with data type        |hangs with data type
                   |Binary[VARBINARY] OR        |Binary[VARBINARY] OR
                   |Binary(fix)[BINARY] AND     |Binary(fix)[BINARY] AND
                   |image data in hsql database |data in hsql database over
                   |                            |8000 bytes

--- Comment #10 from Drew Jensen <drewjensen.inbox at gmail.com> ---
some more information.

In the current code the migration assistant ALWAYS, when it finds a varbinary,
column in the import file, creates the firebird equivalent field with a size of
8000 bytes (even though firebird supports up to 32k in size for this type of
field and I'll open a separate issue for that). // see earlier comments

The test file attached to this issue includes a column with 20k of data.

Running tests with 2K of data in the column did not trigger the hang, running a
test with 9k data in the column did.

The Base HSQLdb UI implementation doesn't allow the user to explicitly set the
size of a varbinary field. The field size grows to accommodate the largest data
value put into it, up to 2Meg (or is it 2Gig?) in size. 

Changing the summary on this issue to just deal with what happens when the
migration assistant tries to put 20k into a 8k sack ;)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20180526/6278c96a/attachment.html>