Bill Thanks for the re-posting!
For all - PLEASE can we make sure we don't turn the answers to this into a 'which is better' contest... They're generally devisive and won't change anyone's mind. Brief list of major differences: - ECLTYPE vs FLAVOR UniData has two built-in ECL types. These broadly represent the two main syntax families for MV systems. In UniData you can switch between them at run time - which can be a benefit but can also cause confusion. UniVerse has an account flavour, which determines the syntax family used for an account. Individual commands can be marked to run in a different flavour, but it is a structural not a run-time change. - File Types UniVerse has broader support for different hashing types to optimise performance. UV and UDT both support dynamic files, but the internal mechanisms are different. UV and UDT both support directory files and can read/write OS level files, though earlier UDT platforms have problems with binary data. Both support index files, though UDT generally makes better use of these for querying. UniVerse supports SQL tables as an extension to the file model, adding security and constraints to the structure. UV and UDT both support triggers, though frankly both could make a better job of them. Both file systems today are extremely stable. - Basic Both support the same standard functions, though UniVerse BASIC is wider - more of a superset - and looser. Most of the innovation has come from UniVerse originally, but most of that has now fed into UniData so the two are a lot closer than in the past. Examples include the socket API, (finally) mixed case coding, SOAP functionality etc. You need to be more careful tuning UniData - it uses global memory blocks to improve efficiency but that can lead to memory leaks between processes. If pushed beyond their limits UV will crash where UDT will carry on and corrupt. Not sure which is better really. But that doesn't happen very often. - Dictionaries Both use the prime style D and I descriptors. UD also has 'V' types - similar to I-types. Only UV really supports the PICK style A and S types. Both support association phrases, but UD makes a separation between MV and SV'ed data - in fact UD has better support for subvalues generally. - Enquiry Here are some big differences. You need to understand the UDT.OPTIONS in UniData - these change the way UniData operates and interprets activities AT RUN TIME. So things like break point processing will change depending on the UDT.OPTIONS in force at that time. This gives more flexibility but also the possibility of someone leaving an UDT option ON that later stuffs up another routine. UniQuery is very much more literal than RetrieVe and won't allow you to mix and match syntax to the same extent. That's not a value judgement - it may or may not be a good thing depending on context! RetrieVe is bound directly into a SQL engine, and the two can be used interchangably to accomplish some very useful tasks, as well as handling set functions, subqueries and EVAL clauses. UniData has some very rudimentary SQL support. Both support XML generation. Neither one offers any real programmatic interaction like the jBASE JQL though. - Interfaces Here again, most of the middleware has started on UniVerse but since been integrated with UD. Both support UniObjects - the best middleware bar none. Both support ODBC equally badly, though in different ways. But you can get round some of the performance issues with UniVerse ODBC better than you can with UniData by poking into the engine using CALL and NATIVE statements. But neither is up to much in this arena. - Scalability and Robustness Both scale. Both are robust. - Which do I use? Both. I do all my development on UniVerse, but I've had more UniData clients. Regards Brian ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
