Back to index


Summary of OOFILE compared to POET and NeoAccess

NOTE: the following points were compiled with publicly available documentation for NeoAccess and POET, combined with public news postings and private email messages over the last 2 years. Corrections are welcomed.

Advantages of NeoAccess
- it's fast single-user
- is royalty-free
- proven in a number of Mac products (don't know about Windows)
- can be used totally RAM-resident?
- allows single database container file
- sold as a source code product

Disadvantages of NeoAccess
- the integrity of your database depends significantly on user-written code
- it does not appear to have a query language as such, just a collection of functions
- saving data to the database requires significant user code
- cross-platform byte swapping is not transparent - it requires programmer effort
- requires single database container file
- it is a product from a small company

Advantages of POET
- is an established product, largest company of all three
- has a more usable syntax than NeoAccess
- external database manipulation and recovery tools available
- has robust transactions, client-server model etc.
- (also) has an ODMG-compliant query language
- (read-only) ODBC access is possible

Disadvantages of POET
- you must use the database preprocessor and the classes it generates
- has multiple database files (rumoured, not confirmed)
- one correspondent questioned their Macintosh support
- queries are constructed in a long-winded manner by creating
a query object and assigning members
- it is not const correct (this has been reported by a few POET users as #1 dislike)
- it requires royalties for all forms of distribution
- the only multi-user model is client-server
- sold as a binary library product

Advantages of OOFILE
- is based on an established database engine (c-tree)
- has far simpler query construction than any other OODBMS for c++ programmers
- no database preprocessor
- uses standard c++ syntax for all queries and database access
- external database manipulation and recovery tools under development
- option of single database container OR multiple database files, including temporary files
- includes report-writer and gui integration classes
- has a commitment to ODMG-compliance
- it is const correct
- ODBC access is possible under MS Windows
- significantly cheaper than POET
- is royalty-free for single and multi-user fileshared model
- sold as a source code product

Disadvantages of OOFILE
- you have to use the supplied classes, or subclass them.
It is not a general persistence mechanism
- it is a recent product from a small company

OOFILE vs NeoAccess (in more detail)

1) We don't have our own indexing engine. This is both a plus and a minus. We use Faircom's c-tree Plus and sell it bundled. This gives cross-platform compatability with NO effort on the programmer's side. As I understand it, if you want cross-platform you have to use special macros in NeoAccess, when you write and read your data. The main minus is that we are bound by licensing agreements - we can't just decide to sell a cheap version and we have to wear a substantial cost. Thus, the base OOFILE is a few hundred dollars more expensive than the compiled library form of NeoAccess, but cheaper than their source form.

OOFILE will also be extended with other backends such as an ODBC engine, so it becomes more of a middleware product. Since our first release, we have added a simple persistent model and dBase-compatible backends.

2) Because we have persistent attribute (field) base classes, we take care of a lot more issues for you. OOFILE knows how to read and write its persistent objects. NeoAccess requires you to provide the routines to get the objects in and out of the database. This makes database integrity far more dependent on *your* code (a point raised by an OOFILE beta tester who's an ex-NeoAccess user).

3) Our integration with frameworks is both closer and less intrusive. We use mixin classes rather than shoving our own Doc and App classes into the hierarchy. We also provide a lot of helper classes to do the linking between a GUI and the database. There's a bit of a win-win situation for us here. By making the helper classes very easy to setup manually, it also made the code generation easy when I customised AppMaker. Our integration classes provide abstraction of the common tasks such as:
- bringing up an edit dialog by double-clicking a row in a browser
- Firs/Prev/Next/Last buttons inside an edit dialog.

You can literally draw an application in AppMaker, specify the persistent fields and generate a complete working app with no programming required (for something that's just a basic database editor, obviously you would add code in some circumstances).

4) We have a built-in report-writer. The current release puts out character formatted (ie spaces and returns) and two forms of htm. The full GUI version is under development.

Andy Dent, Product Architect, A.D. Software, Western Australia
OOFILE - "the cross-platform OODBMS that speaks c++"
ftp://ftp.highway1.com.au/pub/adsoftware/
http://www.highway1.com.au/adsoftware/


Back to index