Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!nic.MR.NET!hal!ncoast!telotech!bsa From: bsa@telotech.UUCP (Brandon S. Allbery) Newsgroups: comp.databases Subject: Re: LONG data type in Oracle Keywords: LONG, data types, Oracle Message-ID: <1989Sep28.171654.17847@telotech.uucp> Date: 28 Sep 89 17:16:54 GMT References: <203@fjcp60.GOV> <640@daitc.daitc.mil> Sender: bsa@telotech.uucp (Brandon S. Allbery) Reply-To: bsa@telotech.UUCP (Brandon S. Allbery) Organization: _ telotech, inc. - Beachwood, OH Lines: 22 In-reply-to: jkrueger@daitc.daitc.mil (Jon Krueger) In article <640@daitc.daitc.mil>, jkrueger@daitc (Jon Krueger) writes: +--------------- | Long byte strings are second class citizens in Oracle. You cannot select, | join, pattern match, or index on them, or substrings of them. They cannot | appear in the WHERE clause of any SQL query. This is not a data type; this | is shared storage. +--------------- This is true of every relational DBMS with which I'm familiar. I'm working on this, though: there is a set of hooks for Unify's Accell 1.4 which supports text fields, and I'm working on expanded support for both Accell 1.4 and Unify 2000/Accell SQL. (The latter after they ship it to us in (I hope) December.) This support will include format-independence and will hopefully be easily portable to other DBMS packages; at least, I'm trying to achieve that. ++Brandon -- -=> Brandon S. Allbery @ telotech, inc. (I do not speak for telotech.) <=- Any comp.sources.misc postings sent to this address will be DISCARDED -- use allbery@uunet.UU.NET instead. My boss doesn't pay me to moderate newsgroups. ** allbery@NCoast.ORG ** uunet!hal.cwru.edu!ncoast!{allbery,telotech!bsa} **