Well I couldn't resist. First, I support products on both databases.
Both have broadly the same core multivalue features, though with different approaches to syntactic variances: UniVerse accounts are set up with specific 'flavors' (emulations) whereas UniData uses a combination of a run-time ECL type and option settings. UniVerse supports a wider range of dictionary types. UniData handles sub-values better. UniVerse has nicer Basic syntax, though UniData is catching up. UniVerse has far better support for SQL and offers NLS support. Moreover most of the interfaces used today began life on UniVerse. Until recently UniVerse had better memory handling, fewer arbitary restrictions and was more developer-friendly. It has a wider variety of file types and in general terms historically you have been able to do more with it. UniData by contrast is more keyed to the 'pure' database functionality: it has better recovery features and high availability. It probably has better indexing, and may be a better choice for applications that do large numbers of small transactions. Sometimes the huge flexibility you have with UniVerse can be a double-edged sword: the enquiry language in particular can be 'helpful' to the point of giving sensible looking information even when you screw up. UniData is more pedantic in its syntax, which may just be a good thing! To sum it up: As a developer I prefer UniVerse and develop all my UniData stuff on UniVerse platform, BUT if I were a DBA I would probably think different. Over the years the two products have become ever closer. Most of the middleware has been ported across, and the extension APIs for things like socket handling are mirrorred on both systems. And I'd still rather use each of them than the alternatives. Brian ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
