🚀 go-pugleaf

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 (jxs18@po.CWRU.Edu  
<1992Jul20.180830.3368@usenet.ins.cwru.edu>): 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
rebecca@cco.caltech.edu