Re: Non-Unique Index For An SQL Table File

[Charles Wilt <charles.wilt@xxxxxxxxx>]

Unlike DDS, in which you could define a non-unique keyed PF, when
using SQL DDL the resulting PF object will either be uniquely keyed
(by having specified a PRIMARY KEY) or not  keyed at all.

So the the answer to your question is no.

Another option to consider would be to either add an IDENTITY column
to use as the primary key, or perhaps make use of the
GENERATE_UNIQUE() function to add a unique timestamp column to the
table.  Technically, either of these techniques would result in a
single column you could use as a primary key.  However, you could also
add the resulting column as a third component of a primary key with
the other two columns you have defined in the index.

HTH,
Charles

On Sat, Apr 11, 2009 at 8:43 PM, RWMunday <RWMunday@xxxxxxxxxxxxx> wrote:
> Greetings from the sunny beaches of Florida.
>
> Our prime directive in creating files at the client site is to use SQL
> Tables and SQL Indexes.  I was presented with a change to some programs
> which made it necessary for me to have a key on an SQL Table originally
> built without a key.  A separate SQL Index over the SQL table works great
> and prevents duplicate key errors.  For that reason I cannot key the
> original file.  I have found no viable option for specifying a non-unique
> key inside of an SQL table.
>
> Is there a way to build a keyed table with a non-unique key?  I tried
> IGNORE_DUP_KEY without success.  There has to be a combination which works
> within the SQL table.  My key consists of two fields in which identical data
> can appear in the file multiple times.
>
> Thanks,
>
>
>
> Robert Munday
> Munday Software Consultants
> Montgomery, AL
> on assignment in Jacksonville, FL
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.