Attempting to migrate an ODB file with a TEXT table (a table definition linked to an external text file) are ignored.
The migration (assuming no other problems) runs to completion without error but the text table definitions are lost.
(example to follow, but will be an hour or so)
Sorry, I hit save to quickly.
Firebird does have support for external files also but the implementation is somewhat different from HSQLdb.
HSQLdb embedded in ODB files uses a restricted naming scheme for the external files and requires that the files be stored in either the same directory as the ODB file or a directory below that.
Firebird 3.0 also offers this restricted mode for their 'external file' support. Which would, it seems, allow the same restrictions as now.
The fb engine must be configured for this support using the configuration item:
ExternalFileAccess = (None, Full, Restricted)
For restricted mode a list of directories are supplied and relative naming is allowed. ExternalFileAccess = Restrict /some/directory
Two pieces of functionality available in HSQL are not available in fb.
1: The ability to create a text table from a SELECT INTO statement, in HSQL if you supply a file name and it does not exist the file is created with a structure to match the result set and the data copied into it. Under fb you can only do SELECT INTO a text table that has already been defined and that already exists on disk.
2: In HSQL you can change which file file a TEXT TABLE definition points to with a SET command. In FB the table definition must be dropped and recreated to do that.
I don't know what the current configuration setting is. Executing a CREATE TABLE command in the SQL window will run to completion and the table defintion is displayed, but no column information is saved, it is a table with zero columns. (I know, needs a different issue)
One more difference.
Under HSQL text tables may contain blob fields.
Under fb external files do not support blob fields.
Created attachment 141666 [details]
Extract the *.zip-file. Open the database. HSQLDB could read table, Migration doesen't work
I could confirm the buggy behavior.
Extract the attached *.zip-file.
Make a copy of the database in the same folder - the original database is unusable afterwords ...
Open the database.
Press "Yes" to migrate.
This error appears:
*unsuccessful metadata update
*ALTER TABLE Adressen failed
*SQL error code = -607
*Table Adressen does not exist
'ALTER TABLE "Adressen" ALTER COLUMN "ID" RESTART WITH 4'
Table "Adressen" hasn't been migrated.
Firebird doesn't support UPDATE and DELETE for text-tables. So it might be a better idea for some users to import text-tables to internal tables of Firebird. The complete migration of the attached example with the same functionality seems to be impossible to me when reading the documentation for Firebird 2.5.
Seems external tables are disabled for the internal Firebird database. When running
CREATE TABLE TEST_TXT
EXTERNAL FILE 'test.txt' (
message CHAR(100) );
There isn't created test.txt.
When I refresh the tables I could see TEST_TXT - but without any row and any column.
Trying to insert values through direct SQL shows:1:
*Use of external file at location /home/robby_daten/Lotest/test.txt is not allowed by server configuration
The one point: External files are not allowed.
The second: The database is at /home/robby/Downloads/... - Firebird searches for the file at the position I started my LO-testversion.
Now I try to delete the table in my database-file, but it is impossible through the GUI, only works in direct SQL (DROP TABLE TEST_TXT;)
Dear Drew Jensen,
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Still reproducible with
Build ID: dfae42730911256dceb8369528ee9d9944a0fa3e
CPU threads: 8; OS: Mac OS X 10.14.5; UI render: GL; VCL: osx;
Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US