<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 24/06/13 20:38, Jean-Pierre Ledure
      wrote:<br>
    </div>
    <blockquote cite="mid:51C8A023.2010501@ledure.be" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">
        <pre wrap=""><blockquote type="cite"><pre wrap="">I do not see any improvement with having to bundle hsqldb vs. having to bundle firebird.</pre></blockquote></pre>
        If Firebird becomes the default database in Base, it will not be
        a matter of bundling either HSQLDB or Firebird, but of bundling
        <u>both</u> !<br>
        Otherwise what about existing legacy databases ?<br>
      </div>
    </blockquote>
    Not exactly: the plan would be to eventually have a parser that can
    import an HSQLDB database, meaning HSQLDB itself can still be
    binned.<br>
    <blockquote cite="mid:51C8A023.2010501@ledure.be" type="cite">
      <div class="moz-cite-prefix">
        <blockquote type="cite">
          <pre wrap="">The main motivation for the switch was getting rid of java</pre>
        </blockquote>
        AFAIK the main issue in using a HSQLDB database embedded in the
        .odb file is that, when LO crashes, the chance is big that the
        database is destroyed: the recovery process does not recover
        that part of the file.<br>
        Will it still be the case with an embedded Firebird database ?<br>
      </div>
    </blockquote>
    I don't know enough of the background on this unfortunately, so
    can't really comment in depth. I guess it depends on how robust the
    specific database in use is and I haven't seen any reports of
    problems with recovering FB databases. (This may also have something
    to do with the overriding of Javas i/o in order to get hsqldb
    writing directly into an odb file -- Firebird, at least for the
    moment, will be using an external file which is then copied into the
    odb file, which would eliminate issues in that transition.)<br>
    <blockquote cite="mid:51C8A023.2010501@ledure.be" type="cite">
      <div class="moz-cite-prefix"> <br>
        In that context I invite interested people to read a.o. the
        thread published last monday on <a moz-do-not-send="true"
          class="moz-txt-link-freetext"
href="http://forum.openoffice.org/en/forum/viewtopic.php?f=13&t=62419">http://forum.openoffice.org/en/forum/viewtopic.php?f=13&t=62419</a>
        by DACM.<br>
        An extract:<br>
        <blockquote type="cite">Unfortunately, the devs remain
          preoccupied with the embedded database concept based on a
          default database engine. They're literally wasting the summer
          trying to shoe-horn Firebird into Base as the default in order
          to achieve yet another, single-file database (.odb), much like
          we have today with HSQLDB. They don't seem to understand or
          acknowledge that the user community has shelved the concept
          because it is inherently unreliable (<a moz-do-not-send="true"
href="http://www.techrepublic.com/blog/10things/10-reasons-to-split-an-access-database/1119"
            class="postlink">as confirmed by Microsoft</a>: <a
            moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.techrepublic.com/blog/10things/10-reasons-to-split-an-access-database/1119">http://www.techrepublic.com/blog/10things/10-reasons-to-split-an-access-database/1119</a>).

          We've also moved beyond the idea of a default database with
          Base. This actually free's the devs to eliminate <span
            style="font-style: italic"><span style="color: #FF0000">internal</span></span>
          Java dependencies from the entire LibO/AOO code-base, perhaps
          with the exception of the hooks necessary for <span
            style="font-style: italic"><span style="color: #FF0000">external</span></span>
          JDBC support.</blockquote>
        <br>
        Have users been enough involved in the debate so far ?<br>
      </div>
    </blockquote>
    If I've understood correctly the suggestion is to remove the "Create
    a new database" option from the Base startup dialog (which creates
    the embedded database) along with the associated embedded database
    loading code (very little code in Base is embedded specific) in
    order to prevent the use of embedded databases? This wouldn't lead
    to any advantage for external db users, and would massively
    disadvantage embedded db users (e.g. casual users like myself,
    possibly some more serious uses requiring everything in one file,
    ...), so seems to be a bit of a complete non-starter really (not to
    mention increased entry barrier for new users, setup required for
    unit-testing, etc.).<br>
    <br>
    Cheers,<br>
    <br>
        Andrzej<br>
  </body>
</html>