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} **