Created attachment 191891 [details] Zip contains an external Firebird file and Base file, which connects to the same internal database file. The attached package contains a database file "ohnecollviw.fdb", which has been created from an internal Firebird database under OpenSUSE Linux. Connect this database file as external database to a Windows system. There will be shown a table and a view in the tables folder. Click on the view. You will get an error: COLLATION UNICODE for CHARACTER SET UTF8 is not installed. Code for the view ends with …ORDER BY "Nachname" COLLATE UNICODE ASC. Open the ODB-file "DB_ohne_Collation_View_Collation.odb". It's the file from which the external Firebird database file has been created. Start the view. Could be started without any problem. You could find the external database file in the temporary folder of your system. In windows it is always shown in upper cases: FIREBIRD.FDB. You could copy this file and connect this external file to an external Firebird ODB-file. View starts without any problem. When opening this extracted file under OpenSUSE you will get the same warning as you have got under Windows with the OpenSUSE file. It isn't possible to use an extracted file from one system in another if COLLATION has been set. And COLLATION must be set to get the right order when sorting tables, so I set this before creating any table. Result: No table will be shown in other systems if I extracted the Firebird database file in my system.
Confirming also on macOS. firebird_sdbc error: *COLLATION UNICODE for CHARACTER SET UTF8 is not installed caused by 'isc_dsql_prepare' Tested with Version: 7.5.9.2 (AARCH64) / LibreOffice Community Build ID: cdeefe45c17511d326101eed8008ac4092f278a9 CPU threads: 8; OS: Mac OS X 14.2.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
Have setup a new system and got the same buggy behavior with the file I had extracted before and tested then with Win-System. Couldn't open any file I have extracted before with collation. System now is OpenSUSE 15.6, but I haven't installed any Firebird server here. So might be a buggy behavior of external file together with installed Firebird server on the same system…
I'm not able to reproduce it. No error messages Tested with different systems and versions: -------------------- Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 2; OS: Linux 6.8; UI render: default; VCL: kf5 (cairo+xcb) Locale: es-ES (es_ES.UTF-8); UI: es-ES Ubuntu package version: 4:24.2.4-0ubuntu0.24.04.1 Calc: threaded --------------------- Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL threaded --------------------- Version: 7.6.7.2 (X86_64) / LibreOffice Community Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL threaded --------------------- Version: 24.8.0.0.beta1 (X86_64) / LibreOffice Community Build ID: 318462181c709ed29c01eb3239b4d600d7b82ecc CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL threaded
Changed the system here. Tested the attachment again. When creating a new external Firebird database and connect to the database-file "ohnecollviw.fdb", then starting the view I get: COLLATION UNICODE for CHARACTER SET UTF8 is not installed. Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded
(In reply to jcsanz from comment #3) > I'm not able to reproduce it. No error messages > Tested with different systems and versions: Sorry, I didn't the test properly. Now I did it more carefully and yes, the bug is reproducible
I am totally unsure if this is any kind of a bug, even though it definitely works as you described. But 141846 comment 13 mentioned, that there is absolutely no guarantee, that a FDB file would ever work on a system other than was used for its creation. The disc structure is system-dependent; and I am sure that not only 32-vs-64 bit, and little-vs-big-endianness makes difference, but also things like size of long (32-bit on all Windows, 64-bit on 64-bit Linux) could create incompatible differences. Thus, it is possible that collation information is somehow dependent on these details, and we simply see *why* FB databases only may be moved using backup FBKs, not FDBs.