Path: utzoo!attcan!uunet!lll-winken!ames!pasteur!ucbvax!tut.cis.ohio-state.edu!cwjcc!hal!ncoast!allbery From: allbery@ncoast.ORG (Brandon S. Allbery) Newsgroups: comp.databases Subject: Re: Selecting a commercial RDBMS (Request for suggestions) Message-ID: <13661@ncoast.ORG> Date: 20 May 89 16:43:03 GMT References: <3199@tank.uchicago.edu> <2335@laidbak.UUCP> Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery) Followup-To: comp.databases Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 32 As quoted from <2335@laidbak.UUCP> by egn@laidbak.UUCP (E. G. Nadhan): +--------------- | In article <3199@tank.uchicago.edu> cs_bob@gsbacd.uchicago.edu writes: | >I don't know much about Unify, | >but the other three pre-process 3GL programs. | | Unify pre-processed 3GL programs too like the other three -- | INGRES, ORACLE and INFORMIX. +--------------- Only if you use Unify's ESQL product, which didn't exist before Unify 3.2. *All* versions of Unify (well, "old" Unify; don't know about Unify 2000) have direct HLI functions callable from C. !!!NOTE!!! Unify HLI functions are NOT SQL-related! The "upp" preprocessor is just the standard Reiser cpp with flexnames in order to deal with long COMB key components, and using '$' as the trigger to avoid confusing the real cpp. On systems with flexnames compilers, I've patched SCOM to output '#' instead of '$' and used the standard cpp with no problems. Oh, and one other thing: Oracle has a direct HLI interface as well. You code SQL statements in C strings and call Oracle functions to attach input and output bindings and open cursors, etc. From what I've seen of it, it's easier to use the "pcc" preprocessor and embedded SQL. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@ NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser