Bug 90392 - support for OO.o/SQLITE databases and forms
Summary: support for OO.o/SQLITE databases and forms
Status: RESOLVED FIXED
Alias: None
Product: koffice
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Jarosław Staniek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-28 14:03 UTC by Marco Fioretti
Modified: 2006-12-14 12:50 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marco Fioretti 2004-09-28 14:03:13 UTC
Version:            (using KDE KDE 3.3.0)
Installed from:    Unspecified

It would be great to exchange single-file SQLITE databases, with
the relative forms and reports, directly between users of KOffice
and OpenOffice.org. See this page for background:

http://www.linuxjournal.com/article.php?sid=7800

The actual file to be exchanged would probably have to be
a (zip?) archive with the SQLite database and the .sxw (OASIS)
file containing the form/report. In any case, something like
this, that could be exchanged, co-edited, moved easily from
PC to PC without root password or installing anything else
(if you already have KOffice or OO.o) would be very useful.

Maybe this could even be expanded so that it works (assuming
permits and everything else is OK) with real SQL servers.
 
Thanks for your time,

Marco
Comment 1 David Faure 2004-09-28 14:06:14 UTC
Why did you file this as a KWord report, when it looks more like a kexi thing?

Comment 2 Marco Fioretti 2004-09-28 15:13:08 UTC
Because:

1) IIRC, I didn't find kexi into the choices offered by
   the bug filing system. Yes, this is probably my error, but:

2) Since OO.o forms are sxw files, I assumed they would be opened
   with KWord

Marco F.
Comment 3 David Faure 2004-09-28 15:21:21 UTC
> 2) Since OO.o forms are sxw files, I assumed they would be opened with KWord

Ah, you mean those. Yep. Well there is no support for forms at all in KWord yet.

Comment 4 Jarosław Staniek 2004-09-30 00:58:50 UTC
Some thoughts, mostly for people outside KOffice:

My opinion is, that here within KOffice project we've no free resources to support features that are about to be dropped or get obsolete. I am talking about support for forms stored inside word processor documents and spreadsheets.
These features were implemented (quite poor because of lacking VBA compatibility) in OO.org because of demand for with MS Office compatibility. 

Currently, with ver. 2.0, OO.org developers introduce entirely different way for doing forms: in a way that is known in MS Access. So why should we, within KOffice, waste our efforts to implement older way of doing things instead of polishing new implementation, since even OO.org now is going the new way?

And, bit off-topic but related:

Btw, No flames, but my 2c for using flat XML for forms/reports/etc storage: It's so weird idea that I really cannot believe more people agreed on that. Why anybody would want to drop robust relational-db storage, transaction support scalability and better security? Probably the love for doing everything in "the XML Way[tm]" made somebody so blind? :) Even so ancient creature as MS Access is, does embed everything into a relational database. 
Comment 5 Jarosław Staniek 2004-09-30 01:09:04 UTC
One more issue: forms/reports XML schema definition is something not related to the storage issue I mentioned above, so I can see no problem with exchanging Qt's UI fromat and UIML or whatever will be (re)invented. 

There may be possible conflict regarding UI format because AFAIK, OO.o db project tries to be a mirror copy of MS Access (thus, maybe even two-way data/schema exchangability is the dream there?), while Kexi is not (one way data/schema migration is a top priority here).

--
regards,
  Jaroslaw Staniek / OpenOffice Polska
  Kexi project: http://koffice.org/kexi/ http://www.kexi-project.org/
  Qt-KDE Wrapper project: http://iidea.pl/~js/qkw/
Comment 6 Marco Fioretti 2004-09-30 05:14:51 UTC
W.r.t Jaroslaw comments #4 and #5:

end users of all free office suites need the capability to exchange simple
relational databases, with queries, forms and all, in one single bundle/file,
across different office suites, without root passwords or installing anything else. This is a fact (of course no one criticizes the right of a volunteer programmer to do whatever he likes best, or the fact that there are little resources).

I have proposed what, in my understanding, seems the easiest way to achieve
this. If you and the OO.o developers find some other way to do the _same_ thing and maybe much more, it's great, we'll just use it. Please check the discussion in the LJ article forum between the HSQLDB developer and me, about Java and Kaffe.

With all respect, end users do NOT care how something happens, or if something is obsolete. Please remember this if you want KOffice to be widely used outside us geek guys. 

I didn't file this as a KOffice bug by mistake. I don't care if what is started is Kexi, Kword or Kalc, as long as when I get a db attachment in Kmail I can click on it to open it and use the queries. And can do the same the day after
in the office where only OO.o is available.

About forms as xml documents: are you sure that OO.o 2.0 won't use them? The developers didn't tell me this when I interviewed them for the article, only
they were considering HSQLDB. Also see what I wrote in the article about the forms using a format (sxw-> OASIS) that KOffice is switching to.
And is the Qt/Uiml stuff usable to build forms/ queries by an OO.o user?

To sum it up, what is missing is a portable, cross-suite solution for these
simple cases, and, maybe, interaction between OO.o/KOffice developers. XML forms, SQLite, HSQLdb (compiled), whatever, as long as the end result works in that way.

Thanks for your time,

Marco Fioretti
Comment 7 Jarosław Staniek 2004-09-30 11:38:24 UTC
Marco,
you wrote: "About forms as xml documents: are you sure that OO.o 2.0 won't use them?"

By "a way that is known in MS Access" above, I mean not a storage method (although I criticized separated flat files) but a way of designing / laying out forms/reports: 

the old way: as it's in oo.o 1.x now: there are some text boxes and similar db-aware control elements floating around entire writer/calc document, elements are often not protected from accidental damage by user (or at least not enough protected); controls are hard to understand how to edit their behaviour; elements laying out is sometimes solved by using ordinary tables; sometimes there is a need to "patch" their behaviour by StarBasic macros instead of use "friendly" predefined properties; StarBasic introduce terribly com.sun.bla.bla paths, something what isn't certainly for non-geeks, etc. etc.

the new way: as you can see in MSAaccess and can preview in OO.org 2.x series.

From my experience with MSA-like products, I know people are confused using "the one way" of doing things. I suspect that old-style forms come from old ages when MSA and MS Office were totally separated.

I am of course not dreaming that old-style forms will be dropped. OO.org has proven it's #1 priority to rewrite every single MSOffice feature to maintain compatibility, (even if it's theoretically impossible to do right & portable - see MS OLE). This is why I really appreciate this project. On the other hand, even you have mentioned "end users do NOT care how something happens". Very true. They choose easier way of doing things. In my knowledge, the new way is easier for them, more consistent/natural.  That's what I mean, not that I am against interoperability between KOffice/OO.o. It's also my own interes to see _both_ projects doing well.

There are more than one issue, so hmm.. maybe one day I'd manage to write appropriate analysis on kexi-project.org.

-- 
regards,
  Jaroslaw Staniek / OpenOffice Polska
  Kexi project: http://koffice.org/kexi/ http://www.kexi-project.org/
  Qt-KDE Wrapper project: http://iidea.pl/~js/qkw/
Comment 8 Nicolas Goutte 2004-09-30 18:23:48 UTC
To comment #4: OASIS is using XML to go away from binary formats. So do not be surprised that OO goes away from binary formats for databases too.

Also I do not see much a difference between SQLLite which is type-less (everything is a string) and XML for storing data. (That an application wants to store it in an internal binary format to speed up is another problem.)

Also do not forget that one goal of the OASIS file format is to be able to read the file format in future decades. A binary format does not help. (See for example how many applications can still read a DBase 4 database.)

Have a nice day!
Comment 9 Nicolas Goutte 2004-09-30 18:53:52 UTC
The more I think about this problem the less it is a KWord-only problem, so moving it to KOffice/General.

(As for describing forms, OO seems (to plan) to use XForms (http://w3c.org/MarkUp/Forms/).)

Have a nice day!
Comment 10 David Faure 2004-10-01 11:54:40 UTC
On Thursday 30 September 2004 05:14, Marco Fioretti wrote:
> I didn't file this as a KOffice bug by mistake. I don't care if what is started is Kexi, Kword or Kalc, ...
You didn't do that, you filed it as a kword bug :) Nicolas fixed that now.

Comment 11 Jarosław Staniek 2005-05-14 21:46:51 UTC
SQLite support is complete for now. The only feature you may want is loading SQLite db files not created by Kexi: meta data is not present there. We're working on this too.
Comment 12 Jarosław Staniek 2006-12-14 12:50:24 UTC
SQLite support is complete in Kexi. The same for servers.