<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">Le 10/04/18 à 22:36, Wols Lists a écrit : </div> <blockquote type="cite" cite="mid:5ACD2037.9080908@youngman.org.uk"> <pre wrap="">On 10/04/18 16:55, Jean-Pierre Ledure wrote: </pre> <blockquote type="cite"> <pre wrap="">Does this mean that once a .odb file containing an embedded HSQLDB database is opened in LO 6.1 there is no way back ? That file cannot be accessed anymore by a LO <= 6.0 user ? Is this acceptable ? </pre> </blockquote> <pre wrap=""> It's normal to update the on-disk format, with the inevitable consequence that old versions of the program cannot access newer versions of data. </pre> </blockquote> When the database conversion is automatic without a fault back scenario, then the software has at least to *GUARANTEE* that there will be neither data loss nor functional loss afterwards. 1. No data loss ? a) BOOLEAN datatypes are supported only since FB 3.0. Note that LO 6.0 (I've not tested LO 6.1 yet) does not support boolean columns with FB. b) VARCHAR datatypes are limited in size: with FB up to 32K, with HSQLDB up to 2G. The workaround in FB is to use instead BLOB types with TEXT subtype (default subtype = BIN). LO 6.0 does not support subtypes. Shall those cases be solved in LO 6.1 ? 2. No functional loss ? SQL Queries may be flagged as "direct SQL". It means that the RDBMS will interprete the SQL command. FB and HSQLDB respective SQLs are not 100% compatible. Will direct SQL sentences also be converted automatically ? Whar about direct SQL sentences built thru a Basic expression ? They are obviously not convertible. These are typîcal examples of compatibility risks. Probably there are much more ... As a conclusion I call for a manual conversion triggered f.i. by a *Save As ...* menu command (or a similar alternative). Additionally the software modules for HSQLDB support should be kept. Thanks. Jean-Pierre </body> </html>