Currently the auto-migrate function works by adding a firebird db into the ODB content and leaving the existing HSQLdb db files intact. This was presented as a good way not to loose data during the migration in that it would be easy to revert back to the hsqldb:sdbc driver by just updating the settings in the ODB content.
However also as part of the auto migration the function may alter items external to the db (schema) to account for differences between database engines and stored in ODB file content.
For very simple migrations just setting the sdbc setting would be make the ODB usable, however the migration function also supports changes whih would make using the ODB problematic at best, broken at worst.
Possible changes include:
changes to SQL select statements which could be in a querydef, form, report or macros.
Table, View, Column names may need to be shortened during the migration and again that ripples out through the objects above.
Steps to Reproduce:
1. Open any hsql based ODB
2. Start the migration
3. save the file
Firebird database file is included in the ODB, ODB set to use firebird:sdbc; necessary fixups to querydefs, reports etc are done, hsqldb data files remain in file.
User Profile Reset: No
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/65.0.3325.181 Chrome/65.0.3325.181 Safari/537.36
Regarding SQL statements, not all changes would be problematic, particularly if favor is given to changes which would alter statements known to a common dialect.
Regarding forms and reports
Both Form files and report files could be backed up to an added sub list in the odb
add sub list hsqlbak
migration routine does any needed fixup to forms/Form1
Sorry for the noise of multiple comments.
Another issue here is what happens if the user does revert the odb to hsql:sdbc for whatever reason.
Right now that odb would fail an auto migration run because a firebird db and schema exist prior to the function start. It will fail when it trys to create the schema objects.
Sure it could be handled by having the function check or drop it first, but its adding complication that could of been avoided.
ps - the comment about backing up forms and reports should of included:
(by lists I meant directories)
if there was no need to fixup anything in forms or reports just drop the backup directory or leave them there so the file can be reverted to hsqldb:sdbc again.
The migration hasn't be done with only migrating tables, forms and relations. Could be you have to change queries, forms, reports and macros also - and all this isn't saved for the internal HSQLDB.
I couldn't understand why it shouldn't be possible to create the migrated Firebird database as a new database. If I open a database and could change something inside the database, I have write-access. The *.lck-file is also written. The only problem could be there isn't enough space available for a new database in the opened folder. But must of the content of a database-file is the database itself. And if I migrate with two databases in one file the file could also expand to much as described before.
I will set this one to NEW.
Have been thinking this through more, particularly as I keep running more ODB files through and I think I am wrong.
IMO the summary of this enhancement request for the current migration function is LibO should create a backup of the ODB file, as is, as the first step of the migration after the user starts the process.
The old and new databases though should stay in the same physical file.
** Please read this message in its entirety before responding **
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!