NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/mac/database/891

Text File | 1992-07-22 | 5.5 KB | 136 lines

Newsgroups: comp.sys.mac.databases
Path: sparky!uunet!elroy.jpl.nasa.gov!nntp-server.caltech.edu!news
From: [e-mail] (Mark L. Fussell)
Subject: Re: Omnis 7
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: small
Organization: California Institute of Technology, Pasadena
References: <[e-mail]>
Date: Wed, 22 Jul 1992 09:39:12 GMT
Lines: 123



Howdy readers,

My recent posting about Omnis 7 may have been a little to up-beat to handle: my
remarks about Omnis 7 were purely compared to Omnis 5.  Although I think Omnis
7 is the best choice for many database applications on the Mac, it does have a
strong "personality" and is not everything to everybody.  But neither are any
of the other Mac databases.  Some of Omnis's weaknesses are in high level
database functionality.  If that is really a problem for you then connecting
Omnis to an SQL server could provide a very powerful environment.

I started working with Omnis 5 about 2 years ago: with a 50 table, 100 window,
several hundred megabyte multi-user application.  My comment about recent use
of Omnis 7 was just for the upgrade.


Omnis in General
----------------

Again, I wouldn't recommend Omnis to everyone.  Omnis's main strengths are
being able to: develop very sophisticated user-interfaces and reports; make
simple UIs automatically; and work simultaneously on Macs and IBMs.  Any other
features Omnis has just keeps it in the running in the database market, or
allow it to connect to other database servers and be a front-end application.
The program, test, and debug cycle for Omnis is very tight: almost everything
can be tested at any time (i.e. change a window and immediately open that
window).


To me, Omnis's biggest fault is its ability to support spaghetti code, and to
make it get worse and worse in the future.  It takes a lot of thought and
effort to write good code in Omnis, but almost no thought and effort to write
VERY BAD code (not my ideal for a programming environment).  Omnis 7 is a
significant improvement over Omnis 5 in this area: although it allows the bad
it also enables the better.

Some other faults include: incomplete database functionality (no transactions,
combined operations, multi-key joins, triggers, etc.), inability to
write/import standard text code, no data structures, and very poor
documentation for advanced application development.


If you want a much longer list of peeves, I'm sure I can create it.  Omnis
usually makes you painfully aware of its limitations where other programs
simply don't venture into an area to entice there users (i.e. 4th Dimensions
lack of "Omnis lists", multi-windowing, field events, etc.).  BUT if you try to
convert a sophisticated Omnis application to other environments you will be in
for a big shock. And Omnis will look much, much better.



Omnis's Problems
----------------

Returning to the comments by Jerry Sy ([e-mail]
<[e-mail]>): these could be grouped as either
Omnis 7 specific problems or general Omnis problems (which Omnis 7 didn't
relieve).


Omnis 7 problems
----------------


>>>    Fully scrollable/resizeable windows
>  what about this, if you have a window with vertical scroll bars only,
>  you are not supposed to be able to chage the width of your window, only
>  vertically.  well, in omnis, they still allow the user to change the
>  window to any size, horizontally and vertically, which to me is annoying.

VERY annoying and I hope they fix it (can't be too tough).  Any "growable"
window lets the user grow/shrink it to unlimited size.  Being able to limit the
window size either horizontally, vertically, both or neither would be very
useful.


General Omnis problems
----------------------

>  15 character field names
    Mildly annoying, but not despicable.  Now 8 characters WOULD be
despicable.

>  12 index fields.

    This hasn't been much of an issue for me.  You COULD split the file
into two parts to get 11 more index fields (23 + one to connect) -- not that I
would want to unless structurally it makes sense.

    A BIG ISSUE for me has been the inability to join files on combined
index fields, but unfortunately neither can most other databases.

>  I want to purge a 0ne million record databasse.  the only way to do it
>  (in runtime) is to delete it record by record!

    Yep, a drag.  All multi-record operations have to be done one at a time
or brought into a list (one instruction), changed, then written back to disk
one at a time.  In multi-user mode this is generally better than group
operations (unless you have a smarter server), but 4th Dimension's DELETE
SELECTION with a returned lock set makes good sense.


>  In multi-user mode, compare to running in sigle user mode, the program
>  you wrote runs 2 times slower over ethernet and up to 10 times slower
>  in localtalk! even if you set everything to read only!

    This is pretty common for multi-user modes of all applications.  Even
Foxbase becomes much slower (actually, it is proportionately incredibly slow)
in multi-user mode.  This is a good warning to any multi-user database
developers... test the application the way the user will, not in a design
environment.  I would not run multi-user Omnis over Localtalk.

------------------------------------------------------


                                      -- Mark

Mark L. Fussell
[e-mail]