Slashdot Mirror
Trail of Tears: MySQL, ODBC, & OpenOffice 1.0
Joe Barr writes "
I found a wonderful "how-to" piece called "OpenOffice.org 1.0, ODBC and MySQL," by John McCreesh. In the introduction, McCreesh writes about OpenOffice.org 1.0's "best kept secret" -- that secret being the fact that hidden away inside, completely unknown to most OpenOffice users, is a user-friendly front end for databases that is "a Microsoft Access (and more) equivalent." That may be so, but there is a very good reason why it's a secret: it's too damn hard getting OpenOffice and ODBC wired up correctly."
Hard to set up?! Never!
Its mentioned in the documentation, but agreed its a pain, and not fully documented, yet.
I think they are waiting until reporting is done to truely 'support' it..
---- Booth was a patriot ----
The "journalist" who wrote the article said his friend was having a hard time getting MySQL, OpenOffice and Linux (Suse) to work. He then lists that his friend can 1) network computers 2) make anything work in DOS and Windows and 3) simply installed the RPMs.
I'm not sure what the hell qualifies this guy to be able to do much of anything in Linux much less tie MySQL to OO via ODBC.
Yes, it may be unknown to most users, but that doesn't mean it's hidden any more than most features in Office.
Anyway, AFAIK a better (non-ODBC) MySQL driver for openoffice.org has been up there on their to-do list for quite some time.
So why not scratch that itch instead?
Install MySQL?
Better get support contract
Config files scattered
ODBC's pow'r
Links data hither and yon
Like many silkworms
Free office software
Fighting forces from Redmond
Freedom is power
Relevant comments
Readers like them, yes they do
Thoughtful minds welcomed
Lame haikus you say?
OK bub, then write your own
Not so easy, huh?
The Trail of Tears was the forced emigration of Native Americans from the South to Oaklahoma. It was brutal and painful, and something that Americans don't like to talk about.
Yeah lets screw open standards.
Admittely ODBC is/was gennerally improved AFAICT by microsoft, it is essentially still an X/Open standard.
It is availble on many platforms, Mac/VMS/Unix/Windows and probably others too. It is a relative striaghtforward C API for database access. Ok, native access could be quicker but I think you'd find difficulty building a thinner layer for all databse engines.
Lets be honest about this two in many cases I reckon you will find OLE DB implement on top of the ODBC drivers . Not that I've ever used OLE DB being a crossplatform developer.
Master of Peng Shui.Ancient oriental art of Penguin Arranging)
Two points:
... how leet should Linux users be before they can install an MS Access equivalent? On Windows, you can do it with a few clicks. It sounds like you want the Linux equivalent to come with a 10-page exam.
1: The writer of the piece, talking about his install troubles, is a Linuxworld columnist. Now, this may not give them kernel-developer-like skills, but...
2:
-- Yoz
Petty nitpicker
You spoiled the joke entirely
I thought it was good.
Modest doubt is called the beacon of the wise. - William Shakespeare
You get an _isql_ with unixODBC, and an _odbctest_ with iODBC (see http://www.iodbc.org/ - there is choice amongst driver-managers, and iODBC even comes with a gtk config app looking relatively similar to Windoze' ODBC Administrator, if you like that sort of thing).
~Tim
--
Rushing on down to the circle of the turn
>Are there seriously still people who don't have
>MS Office?
There are projects for which the price of MS Windows and MS Office will preclude the project being done. Such things may not matter to you, since you obviously either have working capital or are willing to compromise your ethics. What if your entire expected revenue was less than the price of that software, but the system you want to develop has value other than cash value? Because of the price of Office, you're suggesting that such a project should not even be done.
That's not your call. It's okay that there are alternatives, and that people choose to use them!
-fb Everything not expressly forbidden is now mandatory.
It's probably not unknown to those who've use the StarOffice v5.x database ( Adabas = SoftwareAG ). Granted, OO doesn't have the ODBC driver for that free Adabas database but if you've got the SO v5.x CDROM, you've got the driver.
It's working fine here.
BTW, it might not be well known that the database shipped with Sun's StarOffice 5.2( Adabas ) can be run as a multi-client database if you start the server on the right port. Here's a startup script:
x_server -p 7200
sleep 1
x_start dbaseName
sleep 2
xutil -d dbaseName -u control,user-passwd restart
StarOffice and OpenOffice just need to know where the file "./lib/odbclib.so" is. IIRC
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
It's just like Access? So, it's a form builder and a report generator, with full support for embedding standard platform components, including and compliant script engines? Just like Access does?
So, now I can script Open Office applications using Perl, Python, VBScript, JavaScript, and a slew of of less popular languages, just like Access? And I can bring in components built in any of the standard platform development environment, just like Access can use ActiveX controls?
That's incredibly cool. I'm looking forward to trying that.
Or, do you mean it's another crappy, half assed front end that looks superficially similar to Access to someone who's never bothered to use it?
Slashdot is jumping the shark. I'm just driving the boat.
This certainly isn't the first or last attempt to wrap a user friendly UI on top of MySQL, but I think attempts to push MySQL + a nice GUI as an Access killer are mistaken.
My own experience with Access is fairly limited, but from what work I have done with Access, it seems that the biggest benefit is entirely ignored by this and other products like The Kompany's Data Architect. Access lets you take everything (data, reports, forms, queries, etc) and shove it all into a single portable file. Burning a copy to CD-R or Floppy is a snap, and it seems to be much easier for the clueless to wrap their heads around the idea of a database + reports + forms as a single file. I tried to sell a non-profit organization on the idea of MySQL + custom interfaces as a replacement to their quirky Access databases and they were completely unplussed by the idea.
It seems like such a simple idea to combine perl or Python forms, HTML, XML or PDF reports, and Data into a single gzipped file (maybee even a file that runs on it's own without any third party software other than a perl or python interpriter.) I don't get why so much effort seems to be directed at making MySQL user friendly instead. MySQL seems like complete overkill as an Access replacement. GNutrition is a good example of this problem.. Why in the world do you need a MySQL server for something so simple?
You think that's odd? I've got a co-worker who pronounces EVERY three-letter file extension as though it was a word. "BMP" = "bump"... "DBF" = "dibbif".. you get the idea. I've been thinking about getting him a Mac just so he'd run out of things to say.
connecting OOo with PG via unixODBC was very, very simple. Yes, it involved editing a couple files -- /etc/odbc.ini and odbcinst.ini, but you have templates and you just need to edit them. Of course, you don't even need to edit config files anymore -- use ODBCConfig. It's all there, assuming you do a full RH8 install.
However, I wouldn't be so generous as to say OOo's database capabilities are as good as Access. You can merge print from your database -- that is quite easy. You can edit table structure and data -- OK, but I find phpPgAdmin works better for that. It even has form components and the ability to navigate a database with a form, but personally I haven't mastered this yet and feel it's a bit on the ugly side. Certainly there needs to be better documentation for forms and for the Basic code you may need to put in to automate forms. It also has a visual query designer -- OK.
Overall, OOo's database tools will be useful for some people but it has a ways to go. For forms, I think GNU Enterprise has quite a bit more potential.
I've seen Amazon reviews pasted into /. for a +5 Informative, but I have to admire your sheer gall in pasting in a comment on the same thread from half an hour ago.
;-).
/. karma a sufficiently precious commodity to bother with this kind of thing...
Good idea, though. This being Slashdot, nobody checks for dupes
Hmm, looks like this is a habit of yours. I'm continually amazed that people consider
I'm not sure it's fair to query MySQL ABs role in this - did you try accessing Postgres, Interbase, SAPDB, Sybase, MSSQL, Oracle... through OO with unixODBC? Did they work?
Whilst unixODBC sort of works, I've never had much confidence in it - strikes me as being very much the last resort when every other alternative has been tried. In your favour, the MySQL ODBC driver isn't particularly robust - seems to need a number of workarounds to get reliable access from Access (pardon the pun).
I'd also query the quality and reliability of OOs external database support - I've consistently failed to get any database access via JDBC - works fine from my own Java code but never via OO. The documentation was also non-existent last time I looked.
> that secret being the fact that hidden away inside,
> completely unknown to most OpenOffice users, is a
> user-friendly front end for databases
User-friendly? McCreesh was definitely smoking something if he wrote that
Yes if you are going to compile stuff yourself you need to be prepared to make sure you actually configure things correctly. So that various software parts agree on where things are located.
/usr/share/libmyodbc/odbcinst.ini /etc/. :)
If you just want to use the damn software on the other hand you simply do:
$ su root
# apt-get install unixodbc libmyodbc openoffice.org unixodbc-bin
# cp
# exit
$ ODBCConfig
- use GUI to configure database info
- note you could skip that 'cp' command and
- config the whole thing here, but that seems
- like extra effort to me when a perfectly good
- MySQL config exists already
$ oowriter
- Tools->Data Sources
- New Data Source
- pick ODBC and the name you set up above
- Do your database stuff...
Not exactly rocket science.
The article author is simply an idiot, who wants to make life difficult by compiling software himself without bothering to configure it properly.
it's offensive because the two things are of totally different proportion. (Frankly, calling Bill Gates a Nazi is the same way.) This article's title is like naming your Cisco Router "The Auswitch" because you don't dig the restrictive interface; or equating the VCR with the Boston Strangler.
The Cherokee Nation had a bicameral legislature, newspapers, and cities. This was a full nation that Andrew Jackson forcibly expelled to Oklahoma. Comparing this ethnic cleansing to one's ODBC setup bugaboos is shit-headed.
Hey, I'm not saying whoever wrote this shouldn't be allowed to say it. But neither should that person be kept from derision, like a darling little prince. Whoever thought up the title of this article is a cockmaster. Deal with it.
"Whatever happened to fair use?"
-- Duff-Man
NYLXS did an article on this in the September Journal and will be following up with a series on Open Office.
y sq l.html
http://www.nylxs.com/journal/sept2002/openoff_m
http://www.nylxs.com/journal/
http://www.mrbrklyn.com/amsterdam.html http://www.brooklyn-living.com
He was refering to his "friend Milt" who was the Windows/DOS/Network guy. This is the person I said shouldn't be trying to install it on Linux. Now if he would have tried on Windows that would have made sense.
The columnist is a linux user and as such figured out the problem and posted the solution. Now how much of a user he is can be debated.
You dont have to be "leet" as you put it to install the equivilent in Linux but it helps to have actually been a user of linux beyond "I installed Suse today".
So if the writer and Milt are the same person I guess you're right. Otherwise reread the article, again.
Did anyone else see the sentance:
Powerful words should be used carefully, other wise their glib use leaves our language impoverished and trivialized.
and wonder what g-lib has to do with a conversation on the Trail of Tears? Perhaps I've been coding too long.
You aren't, or you weren't - AFAIR the RDB project at IBM - System R*? - originally called the language SEQUEL (hence Ingres QUEL, which might be the commercial product someone else remembers).
However the IBM TLA police were called in (they turned a number of products into TLAs for some reason) and officially renamed it S.Q.L., so it's an SQL database these days.