I was wondering if internal functions saving to and from an XML data file
(an XML file dumper?) might be sufficient to export/import from SQLite
standard datafile (I mean without having all the data in the same file, but
having multiple files); in any case, export/import functions might be part
of the SQLite library file or alternatively as part of the program that is
using the library;
You could perhaps have separate XML files for each table or whatever;
Importation of an XML file would have to be within the constraints of the
SQLite data structure in any case;
On the other hand I am not sure why there is really a problem: it might be
simpler just to add SQLite compatibility to any program like OpenOffice if
they want to have SQLite as a standard, it seems to me that SQLite is
appearing on most platforms anyway!

Kevin O'Neill

----- Original Message -----
From: "D. Richard Hipp" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 24, 2004 11:29 PM
Subject: Re: [sqlite] again on sqlite as a standard, was: SQLite and OOo


> M. Fioretti wrote:
> >
> >>The main drawback of SQLite is that it doesn't support ALTER
> >>TABLE. It's a big limitation for simple users when building a
> >>database. If this fonctionnality (and a few others) could be add in
> >>a near future, SQLite would probably become the first choice for
> >>OOo.
> >>
> >
>
> ALTER TABLE will probably start appearing (in stages) over the
> next several months.  Rename table and rename column will appear
> first.  Then add column and drop column.  Finally add and drop
> constraints.
>
> >
> > 2)
> >
> >>So I hope that SQLite developpers will be able to work together with
> >>OOo developpers to write an embeded OOo driver for SQLite (not
> >>ODBC), and then to store SQLite database in the future OOo base file
> >>format.
> >
>
> Storing an SQLite database as part of a larger file is problematic.
> (1) The SQLite database section needs to be contiguous and it
> needs to be growable. So at the very least, it would need to be
> at the end of the larger file.  (2) If stored as part of a larger
> file, standard tools (such as sqlite3.exe) would not be able to
> read it since they would not know where to look for the start of
> the database.  (3) SQLite needs a separate rollback journal file
> in order to support ACID transactions.  Perhaps these objections
> could be overcome if I better understood the problem.
>
>
> --
> D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
>

Reply via email to