Re: Duplicating SQL View logical file objects to another library

[rob@xxxxxxxxx]

Traditionally what we do here is save/restore.  I just tested that here on 
a SQL view and it worked great
STRSQL
CREATE VIEW ROB/robdan AS SELECT * FROM ROB/AAAKEY
SAVOBJ OBJ(ROBDAN) LIB(ROB) DEV(*SAVF) OBJTYPE(*FILE) SAVF(ROB/ROB)
RSTOBJ OBJ(ROBDAN) SAVLIB(ROB) DEV(*SAVF) OBJTYPE(*FILE) SAVF(ROB/ROB) 
RSTLIB(ROUTINES)
STRSQL
select * from routines/robdan

But, we always do this for DDS logicals also.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Dan Bale" <dbale@xxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
08/20/2004 04:39 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
<midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
Duplicating SQL View logical file objects to another library






What are the rules for duplicating SQL View logical file objects to 
another
library?

Example files:
  PHYFILE  - DDS Physical file
  LOGFILE1 - DDS Logical file
  LOGFILE2 - DDS Logical file
  LOGVIEW3 - SQL "Create View" file

All files originally reside in LIB1.  When I use CRTDUPOBJ to duplicate
these objects to LIB2, the DDS logicals files LOGFILE1 & LOGFILE2 are 
based
on LIB2/PHYFILE, but the LOGVIEW3 file is based on LIB1/PHYFILE.

I think I've found the answer, although I would appreciate confirmation 
from
others.  Looking at the DSPFD on the LOGVIEW3, even though the CREATE VIEW
statement used did NOT qualify the tables, the "SQL view create statement"
in DSPFD shows that the tables were qualified according to where the files
were found in the library list at creation time.

If so, total bummer!

db

--
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.