Created attachment 166227 [details] Tables with long column names From a file with the built-in HSQLDB database I am trying to copy the table to a file with the built-in FIREBIRD database. I attach the file with HSQLDB. Tables have very long column names. When copying tables containing columns with names consisting of Latin letters or numbers, the column name is automatically truncated and the '1' character is added (without warning). When copying tables containing columns with names consisting of Russian letters the column name is not cut off but the table is not copied without an error message. The same situation occurs when copying from a file with CSV tables.
There are 2 known bugs here : No table or column name can exceed 31 ASCII characters (Firebird limitation), which has apparently been increased to 63 characters in Firebird 4. https://stackoverflow.com/questions/20155517/is-it-possible-to-extend-firebird-table-name-length The LO Firebird implementation uses version 3.x, and so does not support more than 31 ASCII characters. These should be truncated automatically when using the HSQLDtoFirebird migration wizard, as per bug 116987, and an incremental number is added to the end of the string. *** This bug has been marked as a duplicate of bug 116987 ***
As always, I don't insist. However, I want to note the following: 1. I was not talking about migration, but about copying (CTRL-C, CTRL-v). 2. tables with columns in different languages with long column names give different results. English tables are truncated and created (though without a message about truncation), while Russian tables are not truncated or copied. And what I think is the main error without messages. The user will not understand what is happening. 3. Нou can Copy this way not only from HSQLDB but also from files with CSV tables. Migration from HSQLDB in this case has nothing to do with it. By the way, when migrating a table from an example file, tables that were successfully copied when copying from file to file are not copied during migration. I would like to emphasize once again that migration has nothing to do with this. Copy-Paste is used for copying, including transferring tables from dissimilar files (with different sources). The source may have other restrictions on the size of the column (or table) name. And Paste should work uniformly and most importantly give messages when copying is not possible. In my opinion.
I tried a different situation. I tried to copy an existing table in the file (c firebird) with a short Russian column name. Russian Russian column name length was increased during copying (I entered Russian characters up to the end of the name field). After the copy was completed, the table did not appear in the list of tables, and the error was not returned. I do not know if the absence of an error message is an error for you. But please review this situation again. It doesn't exactly apply to migration wizard.
Thanks for your feedback. The copying mechanism from embedded HSQLDB to embedded Firebird via the Base UI is similar to that used in the migration wizard, but clearly the changes made there did not take account of the usual Base UI methods for copying tables (mores the pity). Setting to UNCONFIRMED until the bug is confirmed by someone from QA. I might have time later in the week to look at this, but am pretty certain that at least some of the problem stems from our incomplete implementation of collation support in the embedded Firebird driver. My understanding is that for the purposes of our Firebird support, Russian characters are encoded in UTF over 4 bits, which means that the overall length you are allowed to use with such languages is potentially significantly less than 31 ASCII characters (I believe we have the same issue with Chinese and Japanese characters). Of course, it would be better if we could support all such encodings/collations correctly, but there, we are also hampered by the version of Firebird we are using.
There are different bugs: 1. Field names are truncated, if the string has only characters ASCII-characters and there are more than 30 characters. This is bug 116987. I would prefer to show a warning instead … 2. Field names with non ASCII-characters aren't truncated and the tables won't be imported. It is a special Firebird bug: it will only allow 15 Russian characters when it is limited to 30 ASCII characters. And also here: I would prefer a warning which will show the reason. So you will know the lenght of the field names are the problem … I will set this one to an enhancement request for a warning how many characters are allowed in ASCII and in UTF8. My System: OpenSUSE 15.2 64bit rpm Linux. LO 7.1.5.1.
The different limitations (of table names, field names, etc.) in firebird are expressed in number of octets used to encode the names in the encoding used for the database. In LibreOffice, the encoding is UTF-8; which means that any non-ASCII character is encoded using more than one octet. We using Cyrillic alphabet are lucky to only need two octets per character, so we enjoy a luxury of 15 characters. Many Asian languages require up to four octets; do for them, the limitation would be around 7 characters. The inability to convert is indeed an issue.