Slashdot Mirror

This does not affect the users directly, but it is a major pain for integrators/porters. OO.o has a terrible habit of bundling all of the 3rd-party software packages, that it uses, into its own source tree. I'm talking about (probably missed some):

• agg
• bash
• bitstream-vera
• bsh
• bison
• boost
• curl
• db42
• dmake
• expat2
• freetype
• icu
• jpeg
• firefox (or some other Mozilla-based browser)
• libmspack
• libsndfile
• libtextcat
• libwpd
• libxslt
• neon
• nss
• nspr
• python
• sane-backends
• STLport
• unixODBC
• unzip
• vigra
• xmlsec1
• xt
• zip
• zlib

If they could, I'm certain, they would've bundled Java too, but — fortunately — Sun's license prohibits that... Now I realize, that this is done to offer "a single package" to those, who build it on their own, but nobody does. Everybody gets these from their OS' integrators. And the pain for us is enormous, because to force OO.o build to stop its silly ways is a serious undertaking. For some of the above packages there is --with-system-foo configure-flag, but not for all, and the default is to always use the bundled one, so support for the external ones bitrots quickly...

Most of the local builds don't bother and so end up wasting disk space and CPU-time rebuilding packages, which are external to OO.o. The end results are also bloated, duplicating stuff, that's already installed on the users' systems and without bug-fixes, which have already gone into each of the respective package since its most recent "bundling" into OO.o tarballs.

Download a source tarball and see for yourself... Something like: tar tjf OOo_OOG680_m9_source.tar.bz2 | grep 'z$'. No other software project does this on this scale and for good reasons — it is Just Wrong[TM]. OO.o better clean up their act in this respect...

Here, this little link should provide you with the necessary knowledge to use ODBC which has been
supported since version 1.0

http://www.unixodbc.org/doc/OOoMySQL.pdf

http://www.unixodbc.org/

Both SuSE and Ubuntu offer ODBC. I don't know about centos as I've never needed ODBC on it, but I'm sure it's there, and if not, being open source, it can be downloaded and compiled.

THERE IS NO ODBC FOR LINUX (or equivalent).

"There is no abstraction layer to the database; most work is done directly using SQL. The DB layout is a nightmare, and the queries are painful to look at and even worse to work with."

This is what gets to me about people doing stuff that runs on *nix systems. UnixODBC http://www.unixodbc.org/ gives you the database abstraction layer. Why Heck! Using UnixODBC in a PHP project like OsCommerce should allow it to run unfettered on Windows servers. The only problem I've run into with UnixODBC is some vendors odbc drivers are sparingly implemented (MySQL's driver comes to mind. The FreeTDS driver (for Sybase/MS SQL Server) is quite good).

From the UnixODBC website: "The two major advantages of choosing to code an application to the ODBC API are;
Portable Data Access Code
The ODBC API, as outlined by X/Open and ISO, is availible on all major platforms. Microsoft platforms include many enhancements to this specification; these enhancements are also supported by unixODBC "

ODBC?

from http://www.unixodbc.org/ --
"Also; ALL unixODBC development is and will be distributed under GPL or LGPL. The LGPL on libs will ensure that commercial solutions will be able to utilize unixODBC."

Emphasis mine.

There isn't?

I just finished a project that accesses SQL Server from a Linux/Apache/mod_perl app using ODBC via the FreeTDS drivers. (Don't ask, client requirement.)

Granted, not all of the unixodbc drivers are free. But then, they aren't in MS land either, although you might not notice because you're paying for them via a bundle.

OpenOffice.org is still missing a replacement for Microsoft Access, a graphical database design program. Novice or casual users do not want to learn PHP.

Look at the "Database User Tools" or the "OpenOffice.org 1.0, ODBC, and MySQL 'How-to'" for an overview of how it works. This is much improved in OOo 2.x, which will be out early next year. Snapshots of OOo 2.0 are available for download and testing.

For a good bit more work, but less money and the karma boost of avoiding proprietary (and somewhat buggy) Access, it looks like OpenOffice has rudimentary support for databases. Take a look at the UnixODBC project, specifically this PDF, which seems to do a decent job of explaining the steps involved. Note that I've never tried this, but it certainly looks workable. As a bonus, you should be able to use any database with an ODBC component.

Of course, you could always go with dBase (who bought some of the rights from Borland), who have a web enabled dBase version. It'll need to be hosted on a Windows machine, it looks like though.

You may also want to take a look here which lists Windows and *nix xBase compatible programs. xBase was (is?) a standard that dBase, Clipper, FoxPro and others adhered to. Perhaps you'll find something there. Also, there was a dBase for UNIX at one point...I don't think it's still for sale, but you may be able to turn up a copy on eBay or something.

One last suggestion would be KNoda which is a KDE frontend that allows for queries, forms, and table design. It looks a bit like Access, though, once again I haven't tried it.

That should start you on your research...good luck.

This document has been around forever; I could have sworn that I found it in the first place via Slashdot.

I was looking at it a couple months ago to see if it would make a possible replacement for Access. It appeared that OpenOffice could give a nice frontend for simple forms, but not much beyond that. I didn't want to mess with ODBC, and wasn't about to install MySQL on my work machine.

Access is great for single user desktop applications, but it doesn't really scale that well, even with SQL support.

VB is normally the tool of choice, but I'm caught between the .EXE version becoming obsolete, and our organization not being ready to jump onto the .NET bandwagon.

I'm looking forward to seeing what's new with it in the next OpenOffice release.

http://www.unixodbc.org/
Read... Enjoy...

However, you'll be happy to know that we've wrapped all of the database calls into a data store API.

That depends. Did you use your own data store API, or use one which is already becoming a standard? If you used your own, then I am not happy. In order to create the largest interoperability, someone will have to write an interface between your API and a more widely used API; Or, a module must be developed for each db, which seems wasteful.

Then again, I haven't yet done a lot of research into what's out there. A quick search indicates:

• EasySQL
• Freeodbc++
• unixODBC

Again, I really don't know how far any of them are along.

Also, to those who say they don't want to install a RDBMS to store mail; Yippee. There are a number of small, free, and functional SQL databases these days. MySQL, for example, is LGPL, and if your product does not require it to operate (IE, if you're supporting more than one RDBMS) then you don't need a license -- Which is the idea. MySQL is small, fast, functional, simple, and easy to set up; A large MySQL db should be faster (one would hope) than a large set of dbm files :)

Consider my two cents pitched in.

That does raise a interesting question, I assumed, that the release day was today, how long ago was it frozen ?