Posted: Mon May 02, 2005 4:16 pm Post subject: NeoOffice/J first timer reaction
Wow, NewOffice/J is surprisingly terrific. Now that you're close to release, any feel for when you might tackle OO 2? I've been working with OO 2's Base database, which is a great addition to the suite. MS Office has never had a database in the Mac version, so having Base would be sweet.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue May 03, 2005 8:11 pm Post subject:
Unfortunately the move to OOo version 2 is a quite significant amount of work...probably about a year or more.
Base is kind of a cop-out as well. If you dig a bit deeper, you'll find that you can get a significant amount of "Base" from the way it was embedded before; simply configure your data source and use Writer to construct your forms. The reason for inventing "Base" wasn't because OOo 1.x didn't have the capabilities to do database forms in previous versions. Wrapping things up in "Base" just brings those capabilities more to the forefront for those giving the suite a cursory glance.
Unfortunately the move to OOo version 2 is a quite significant amount of work...probably about a year or more.
Base is kind of a cop-out as well. If you dig a bit deeper, you'll find that you can get a significant amount of "Base" from the way it was embedded before; simply configure your data source and use Writer to construct your forms. The reason for inventing "Base" wasn't because OOo 1.x didn't have the capabilities to do database forms in previous versions. Wrapping things up in "Base" just brings those capabilities more to the forefront for those giving the suite a cursory glance.
Actually in the days of Star Office (I think that I still have a copy on tape somewhere), there was an included database product, of a sort. I don't know what happened, but I'm suspecting that Base is a resurection of the attempt to add in a minimumally functional database, on the level of Access (TM). I would like to see something a little more robust for a database, but not on the level of Sybase or Oracle.
Just my thoughts on this subject.
And I don't think it will take a year to move to OOo 2.0, but it will not be an 'overnight' task either.
Posted: Thu May 05, 2005 1:49 pm Post subject: I beg to differ. Base is not a "cop-out"
OPENSTEP wrote:
Base is kind of a cop-out as well.
ed
Let's review our history for a bit.
One of perhaps several reasons why Access destroyed the once high-flying Paradox and dBASE in the mid 90s was because Microsoft introduced to the desktop the concept of the database file type. At that time the "industry standard" even with desktop systems was database = folder. A "database" with Paradox and dBASE was a separate folder containing a collection of files. Each table, index, memo, report, form, query, etc. in the database was a separate file in this folder. Imagine if your word processor acted like this. Well, actually it did at one time. Word for DOS kept style sheets in separate files and stored bitmap files external to the .doc file. Now they're part of the .doc file and users would never go back to the old way of splitting up the document into separate files.
The introduction of the Access .mdb file, where all tables, queries, forms, and code modules are stored in a single file, is exactly analogous to the way other "document-centric" programs like Word, Excel and PowerPoint store their content. Like any revolutionary concept, this is both simple and obvious to the user.
There are perhaps at least 3 possible objections to a database file type: (1) Prone to corruption, (2) Proprietary format, and (3) Not cross platform. In my experience, corruption of .mdb files has not been a problem and certainly less of an issue than having a hundred files in a folder, any one of which if replaced by the wrong version can bring the db app down. However, Microsoft fails in a big way on (2) and (3). (2) is addressed nicely by OO Base's .odb file type and (3) could be too if OO 2 becomes available for Mac users via NeoOffice/J.
Like Access, Base's .odb file can connect to external databases or contain tables itself or have a mix of both. And although Base doesn't have VBA, it does support a standard scripting language like JavaScript.
I consider a database the 2nd most important application in an office suite behind the word processor (most Excel users are trying to simulate a database with their spreadsheets and are really using the wrong tool). It always bugged me that Microsoft didn't bring Access over to the Mac. It really left MS Office for the Mac a poor cousin to the Windows version.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu May 05, 2005 7:24 pm Post subject:
Oh, I'm not disagreeing that a good entry level database app is necessary (how may offices are still using FileMaker?)...I wasn't trying to say that was a bad idea.
I was more trying to say that Base is a "cop out" because a large part of the functionality within Base is already in OOo 1.1. Writer has the ability to make forms with graphical elements that can be tied to a database backend. It's a bit more involved then using the wizards of the new interface, but a surprising bit is already possible
the 'only' problem with this kind of works is that the graphical tools of neooffice are useable only in a little way: you can not build a mysql table using the table editor of neooffice (it gives problems), and the graphical tools used by the query have not many sql options: in a word you can not build sophisticated query or form without open a mysql book.
And working with form, well, again, building subform is a 'macchiavellico' game, and often you need program macro... so you need to open the staroffice 7 basic manual that is not so clear... The form tabls are not well-integrated with the rest of the application too: if you 'select all' inside of a form-table 'cell', neooffice select the text background of the write document... and other little problems.
I have not tryed the base section of Oo 2.0, but I hope it could be more user friend for the form build (and subform), and have a simple way to build basic macros without have to program it.
I'm building this little database hoping to move my actual big spreadsheet to the database, but I'm quite scared for those problems. For example calc values is quite hard.
And yes, have only a big file with all the datas is not a bad idea... actually to backup the database I have to make a database dump, to copy the write form files, and to copy some files from the neooffice's user folder...
Your Writer-based "form" looks nice. I'm impressed that you were able to create a functional database app within a word processor.
It remains to be seen if OO's use of Writer both for form/report design and viewing is a good idea or a bad one. Most db's have dedicated report and form designers and viewers, recognizing that some db things just don't make sense in the context of a word processor, say.
Access has highly refined form and report designers/viewers. Unfortunately the design elements can't be used with other software. Even the report viewer can't save a report to a standard rtf document without loss of a lot of formatting. The only way to save a viewed Access report and retain all formatting is to save it to a "Snapshot" file (.snp). This snapshot is a perfect replica of what's viewed and printed, but it can't be edited, or even inserted into another document, only viewed and printed, and only on Windows.
Base's report designer creates what appear to be standard Writer documents. And viewing a report creates a document as well. This would appear to be a good idea, using Writer for these purpose instead of creating another (complicated) piece of software to do design and viewing of forms and reports.
Unfortunately, saving a viewed report in Base to any number of formats (.odt, .doc, .pdf) generated junk. Either the formatting of the report tables was all messed up or the tables didn't contain any data at all. Ouch!
Parts of Base look like a prototype or proof-of-concept, not beta software. I sure hope they don't ship it with the current limited features and problems.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri May 06, 2005 8:36 pm Post subject:
I think you just hit the nail on the head of why I'm so unimpressed with the 2.0 Base. It's just a wrapper for those old style Writer forms with a different name. To me it seems more just like a "repackaging" of what was there into a new top-level app in order to get a checkmark in that "competes with Access" column on a marketing featurelist. While some of the new wizards for MySQL and the like are nice, there's nothing groundbreaking that makes Base anything revolutionary when compared with 1.1.x...and definitely nothing that makes it an Access killer.
The beauty of FileMaker was the same beauty that HyperCard had. It was a great way to visually construct a database. The form layout itself nearly designed the entire database for you. Granted, that made it a pain in the ass to integrate with other databases. On the flip side, it did allow non-technical people to design and implement databases, and on top of that, databases that were actually usable.
For open source Access killers, I've definitely not looked to OOo. More promising projects to me have been :
I've kept my eye off an on at the two of them to see if either can get to the point where they can become part of NeoJ (similar to how I'm still searching for a good Visio replacement). I was really stoked about Rekall when it was released but didn't have time to focus on an OS X port. I believe one is in the works and has reached prerelease.
The first link looks like a project that's going nowhere fast. The second link is for a project with no Mac or Windows versions so it fails the cross-platform test.
I still think Base is the future, but I'm surprised at how little they've improved the forms and reports over 1.1.14 outside of a couple bug fixes. NeoOffice always seems to lose columns I've added to a table in a subform. No matter how many times I insert columns, the next time I open the .sxw the columns are gone. OO 2 seems to have fixed this. Also, I never could get a query created in NeoOffice's Tools | Data Sources to work correctly in a subform - only an SQL statement inserted in the Content field would work.
One of the biggest limitations of OO "reports" is that tables in a subform can't resize themselves vertically. This is fine for a form, where you provide a scroll bar for moving between table rows, but try operating a scroll bar on a printed report. Banded report designers handle this effortlessly, but since OO uses a table with a fixed vertical dimension, you have to size it to handle the worst case maximum number of records. This is a non-starter for most reports.
The queries created by OO are very weak too. In Access, query fields can contain expressions, including references to functions that you write in VBA. This adds almost limitless power and allows complex expressions to be moved into VBA code where they can be documented and tested independently of the query. I don't see anything like this in OO except for a handful of uninteresting aggregate functions.
I agree that at present Base is not much more than a feature list item. But the structure is there if they ever decide to get serious about databases.
NeoOffice always seems to lose columns I've added to a table in a subform. No matter how many times I insert columns, the next time I open the .sxw the columns are gone.
This is a Oo x11 mac/neooffice/j bug, not a Oo bug.
I found a work-around savings forms in staroffice file format instead neooffice file format.
Also, I never could get a query created in NeoOffice's Tools | Data Sources to work correctly in a subform - only an SQL statement inserted in the Content field would work.
weird... I have some subform linked to query... what is the problem?
NeoOffice always seems to lose columns I've added to a table in a subform. No matter how many times I insert columns, the next time I open the .sxw the columns are gone.
This is a Oo x11 mac/neooffice/j bug, not a Oo bug.
I found a work-around savings forms in staroffice file format instead neooffice file format.
Also, I never could get a query created in NeoOffice's Tools | Data Sources to work correctly in a subform - only an SQL statement inserted in the Content field would work.
weird... I have some subform linked to query... what is the problem?
f.
In a subform linked to the main form via Link master fields/Link slave fields, the subform displays all records with NeoOffice, not just those for the current master form's record. The only way I could get this to work was to enter an SQL statement that explicitly filtered out the other records using WHERE =:
Just tried this with Base and it works fine there, with the subform displaying only the records that match the main form's current record.
I would test my NeoOffice .sxw file with OO 2 too, but it doesn't seem to have the ability to create data sources anymore (no Tools | Data Sources command).
Also, I just discovered that Base doesn't appear to support storing of macros in the .odb file the way the other file types do. Very weird since a database is probably the place where macros would be used the most. In the macro organizer, the only macros listed are for "My Macros" and "OpenOffice.org Macros". In .odt files, for example, the organizer also lists the current document's macros.
sigh. i don't like access. i try not to actually hate things, because hate is bad (dark side and other such things) but it takes effort when it comes to access.
the UI is awful. you basically have to know how the thing works. granted i haven't used it much since access 2000...
oh and wasn't backwards compatible. and i dislike VB. which is not a real programming language.
there may or may not be a summer internship story associated with these feelings...
In a subform linked to the main form via Link master fields/Link slave fields, the subform displays all records with NeoOffice, not just those for the current master form's record. The only way I could get this to work was to enter an SQL statement that explicitly filtered out the other records using WHERE =:
Ah ok, yes this is true. But I think is correct in subform: you build a query and when you finish it, open the SQL window and add a WHERE <field of the main form> = variable:
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
