Re: Reality check on PFs created as SQL TABLEs

Rob Berendt <[email protected]> Wed, 10 Jun 2026 14:19:20 -0400
Newsgroups gmane.comp.hardware.ibm.midrange
Message-ID <CAPJ+qQMgL1b-ucr+MN=0xGK_1BOpDtNN0ygG5W_6=77-S7yHGA@mail.gmail.com>
If by "more than one inherent key field" do you mean a key on an order
detail file by order# and line#?  You just have to do it right.  Instead of
putting the PRIMARY KEY on an individual column you put it at the end.
CONSTRAINT iim_pri_key PRIMARY KEY (Order_number, order_line)

On Wed, Jun 10, 2026 at 2:12 PM James H. H. Lampert via MIDRANGE-L <
[email protected]> wrote:

> On 6/10/26 10:43 AM, Daniel Gross wrote:
> > Yes - primary key constraint is the way - the primary key "index" is
> > embedded in the table/PF object.
>
> Thanks. That worked, and the syntax is correct.
>
> I could have sworn that you couldn't have keyed SQL tables . . . and I
> just found the exact same constraint clause in *SQL for Dummies,* after
> having created a test table using the clause.
>
> I don't suppose it's possible to create an SQL TABLE with more than one
> inherent keyfield, the way you can with a DDS-defined PF, is there?
>
> On 6/10/26 10:51 AM, Dan Bale wrote:
> > If I'm not sure how SQL "replicates" a DDS feature, I'll use the
> > Generate SQL function in Run SQL Scripts to generate the converted
> > SQL source for DDS PF & LF objects.
> I tried an experiment. With PF "FOO" generated from the following DDS:
>
>      A          R FOOBAR
>      A            FIELD1        10A
>      A            FIELD2        10A
>      A          K FIELD1
>      A          K FIELD2
>
> I tried "Generate SQL," and got:
>
>    CREATE TABLE MERCURY.FOO (
>    --  SQL150B   10   REUSEDLT(*NO) in table FOO in MERCURY ignored.
>    --  SQL1506   30   Key or attribute for FOO in MERCURY ignored.
>         FIELD1 CHAR(10) CCSID 37 NOT NULL DEFAULT '' ,
>         FIELD2 CHAR(10) CCSID 37 NOT NULL DEFAULT '' )
>
>         RCDFMT FOOBAR     ;
>
> So it looks like "anything DDS PFs & LFs support, SQL does as well" is
> indeed an oversimplification.
>
> Then again, Theory and practice are the same in theory, but not
> necessarily in practice. (Paraphrased from a maxim falsely attributed to
> Yogi Berra, among others, that may have originated with Jan van de
> Snepscheut.)
>
> --
> JHHL
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: [email protected]
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/midrange-l
> or email: [email protected]
> Before posting, please take a moment to review the archives
> at https://archive.midrange.com/midrange-l.
>
> Please contact [email protected] for any subscription related
> questions.
>
>
-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: [email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: [email protected]
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact [email protected] for any subscription related questions.