This bug appears while migrating from HSQLDB to Firebird with the Migration-wizard. firebird_sdbc error: *unsuccessful metadata update *CREATE TABLE Rechnungsinhalt failed *Dynamic SQL Error *SQL error code = -204 *Data type unknown *Implementation limit exceeded *COLUMN <Missing arg #1 - possibly status vector overflow> caused by 'CREATE TABLE "Rechnungsinhalt" ( "ID" INTEGER NOT NULL, "Rechnungsinhalt" VARCHAR(10000) NOT NULL,PRIMARY KEY("ID"))' /home/buildslave/source/libo-core/connectivity/source/drivers/firebird/Util.cxx:68 So I tried it later in the Firebird-database with Tools → SQL: CREATE TABLE "Rechnungsinhalt" ( "ID" INTEGER NOT NULL, "Rechnungsinhalt" VARCHAR(10000) NOT NULL,PRIMARY KEY("ID")) doesn't work. If I set it to 8000 instead of 10000 it will accept the command. Note: Firebird supports 1 to 32.767 Bytes for a Varchar-field. But we have also problems to count the characters right way, because there are characters, which will need 2 byte or 4 byte. Seems this limit has been set in the driver from LO to 8000 - for 4 byte characters... The bug appears in Firebird in LO 6.4.4.2 on OpenSUSE 15.1 64bit rpm Linux.
... and this bug should have been fixed since some times: https://bugs.documentfoundation.org/show_bug.cgi?id=105604
@Julien, I thought you might be interested in this issue
Even if I knew how to retrieve character set, since UTF-8 may use 1 or more bytes, no idea how to fix this. => uncc myself.
In theory, it is supposed to be: Char and Varchar: 32767 bytes for encoding in single byte character encoding according to : http://www.firebirdfaq.org/faq61/ but then I seem to recall that we encode using 4 bytes per character because we accept UTF-8, thereby reducing the total possible length of a VARCHAR field to about 8K ? See also: https://stackoverflow.com/questions/14682709/how-to-declare-a-field-as-varcharmax-in-firebird
FWIW, confirming. Pretty sure we had a related bug report discussing the merits of allowing the user to specify character encoding upon table creation in the GUI ?
Indeed, utf8 requires 4 bytes max so Firebird can only use 32767 (or rather 32765?) / 4. By default, databases are created with utf8 but instead of creating a specific gui to change this, we can also change the database character set at the beginning, eg: alter database set default character set ascii; (seen https://github.com/FirebirdSQL/firebird/issues/5049) Of course, there's still the migration pb. Now do you really have a VARCHAR column in HSQLDB containing so much characters? I thought it would be a LONGVARCHAR which seems to be mapped as a BLOB.
(In reply to Julien Nabet from comment #6) > > Of course, there's still the migration pb. Now do you really have a VARCHAR > column in HSQLDB containing so much characters? I thought it would be a > LONGVARCHAR which seems to be mapped as a BLOB. No, it is a varchar-field. Created this in a table for collecting all goods and prices for bills. But it will also work with 8000 characters … Has only been an example. 8000 characters will be enough to fill a bill with up to 3 pages. And a CLOB field will do the rest. Better UTF8 and CHAR_LENGTH will work the right way. I will close this bug as worksforme.