Re: SQL statements for physical and logical files

Hi Peter

Yes, I didn't say anything about that. I'd already spent far too many words on this, eh?

But it makes me think - a view is almost nothing more than a container for the SELECT statement - maybe completely so.

Whereas an LF without key, one that just presents a subset of the fields, is more like a view in its output, seems to me. But I suspect there is a difference in processing - an LF doesn't have to go through optimization, so far as I know - a view will be run through the optimizer first, as part of executing the encapsulated SELECT statement.

More recent kinds of indexes seem to be more like the LFs we use that have a key, as well as, perhaps, a subset of the fields. IIRC, indexes and keyed LFs (and keyed PFs)

Seems that the set of SQL statements generated to replicate an LF could be an interesting set - I've not done that much, certainly not recently. I've been more interested in generating SQL for PFs.

Regards
Vern

On 2/11/2017 1:57 PM, Peter Dow wrote:

Hi Vern,

While probably not true for all SQL objects, for a view, the create statement *is* stored within the object:

create table PDOW/TABLE1 (
Fld1 char(5) not null with default,
Fld2 dec(5,0) not null with default);

create view PDOW/TABLE1V as
select Fld2, Fld1 from PDOW/TABLE1;

DSPFD PDOW/TABLE1V
File Description Header
File . . . . . . . . . . . . . . . . . . . : FILE TABLE1V
Library . . . . . . . . . . . . . . . . . . : PDOW
Type of file . . . . . . . . . . . . . . . : Logical
File type . . . . . . . . . . . . . . . . . : FILETYPE *DATA
Auxiliary storage pool ID . . . . . . . . . : 00001

<snip>

Number of triggers . . . . . . . . . . . . : 0
Number of members . . . . . . . . . . . . . : 1
SQL view create statement . . . . . . . . . :
CREATE VIEW TABLE1V AS SELECT FLD2, FLD1 FROM PDOW.TABLE1
Record format selector program . . . . . . : FMTSLR *NONE
Records to force a write . . . . . . . . . : FRCRATIO *NONE

DMPOBJ PDOW/TABLE1V
LINES 0002E0 TO 00035F SAME AS ABOVE
000360 80000000 00000000 084A72E3 C20015D0 00001D70 000005D0 00250000 00000000 * ¢ÊTB } ø } *
000380 00000000 00000000 00000000 00000000 00000000 00000000 00000142 C3D9C5C1 * âCREA*
0003A0 E3C540E5 C9C5E640 E3C1C2D3 C5F1E540 C1E240E2 C5D3C5C3 E340C6D3 C4F26B40 *TE VIEW TABLE1V AS SELECT FLD2, *
0003C0 C6D3C4F1 40C6D9D6 D440D7C4 D6E64BE3 C1C2D3C5 F1404040 40404040 40404040 *FLD1 FROM PDOW.TABLE1 *
0003E0 40404040 40404040 40404040 40404040 40404040 40404040 40404040 40404040 * *

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx>
pdow@xxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxx> /

On 2/11/2017 5:56 AM, Vernon Hamberg wrote:

Hi Alan

I don't understand your first sentence - well, I might understand it mostly, and I'm pretty sure it's not exactly correct.

I don't know what "...stored in SQL..." means - the fact that you can generate (not retrieve) the SQL statement that will create the equivalent of a PF or LF does not mean that the statement is stored anywhere. I'm very sure the statement is not stored.

There ARE - I know you know this, but for the rest of the world! - there are system tables that hold information ABOUT the several kinds of database objects - tables that contain a list of tables, of views, of indexes, of columns, of keys, etc.

A very important point - SQL DDL-based tables and DDS-based PFs are 95% identical, with the tables having some additional attributes and behaviors - but basically, SQL tables inherit the attributes and methods of PF objects and add some. This is demonstrable using the DMPOBJ command on both types - one will see the same structures in both - various spaces, format objects, member objects, etc.

As for Data Studio, someone needs to confirm that PFs and LFs even show up in the lists of tables or views or indexes. I've not looked at Data Studio for years, and it used to have almost no AS/400 or iSeries support. I did a google on "data studio" "ibm i" - quotes are included to limit the results - and find a quick start for DS - for linux, unix, windows only - article by Jon and Susan from 2013 with a quick ride that is positive, a PDF on doing projects there - if PFs & LFs are listed in DS, it should be possible to use it to generate the SQL statement or statements to create the SQL equivalent of them.

HTH
Vern

On 2/10/2017 4:54 PM, Alan Campin wrote:

All DDS or SQL defined tables are stored in SQL and you can retrieve the
source was SQL at anytime. I just using Ops Nav and go in and right mouse
on a table name in the database and say generate SQL. Make sure you take
the option to include system names. You should be able to do the same thing
in Data Studio.

On Fri, Feb 10, 2017 at 2:03 PM, William Howie <
William.Howie@xxxxxxxxxxxxxxxx> wrote:

Hello all,

Can anyone tell me if there is a system table on the iSeries that stores
the SQL statements that would be used for creating a particular physical
and/or logical file? Does the file have to have been originally created
with SQL instead of DDS for this kind of information to even be kept
anywhere or is it stored somewhere for all files? On a related note, does
the use of IBM Data Studio in any way help to facilitate finding this kind
of information? Any info would as always be appreciated. Thanks!

Bill

AOMobile - AmTrust Financial Services, Inc. Download on the App Store℠<
https://itunes.apple.com/us/app/aomobile/id626262396?mt=8&uo=4> | Get it
on Google Play™<https://play.google.com/store/apps/details?id=com.
amtrust.aomobile>
- Apple and the Apple logo are trademarks of Apple Inc., registered in the
U.S. and other countries. App Store is a service mark of Apple Inc.
- Android is a trademark of Google Inc.

________________________________
Confidentiality Notice: This email message is intended only for the
individual or entity to which it is addressed. This email may contain
information that is proprietary or privileged, confidential and exempt from
disclosure under applicable law. If you are not the intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you received this email by
accident, please notify the sender immediately and destroy this email and
all copies of it.
--
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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD