Re: SQL Question -- MIDRANGE-L

Thanks Rob



Alan Shore

NBTY, Inc
(631) 244-2000 ext. 5019
AShore@xxxxxxxx

midrange-l-bounces@xxxxxxxxxxxx wrote on 12/20/2006 03:33:19 PM:

As said earlier, you can connect to a different remote system; just not
two systems at the same time.  For instance, you can do something like
CONNECT MyLocal
Select * from myfile
CONNECT MyRemote
Select * from myfile

But you cannot connect to both at the same time and do something like
Insert into MyLocal.myfile
(select * from MyRemote.myfile)



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





Alan Shore <AlanShore@xxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
12/20/2006 03:27 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: SQL Question







Thanks for your reply Vernon
I know that SQL cannot use DDM files, but I have heard that via SQL you
can
connect to another system and run your SQL statements from a different
system (I'm not too sure how this is done, though) but I was just
wondering
if what I described in my question was possible, and if so, how.



Alan Shore

NBTY, Inc
(631) 244-2000 ext. 5019
AShore@xxxxxxxx

midrange-l-bounces@xxxxxxxxxxxx wrote on 12/20/2006 03:10:53 PM:

Alan - SQL knows for diddly about DDM - it cannot use DDM files.
Also, any SQL statement runs on one and only one system at a time -
even if you have multiple connections, you can have only 1 active.

What about using remote journaling? This could replicate changes as
they happen. Just a thought.

SQL is not made for system maintenance and object creation in the way
you are describing it = IMO

Merry Christmas!
Vern

At 01:53 PM 12/20/2006, you wrote:

Thanks for the reply Jerry.
That's one procedure we are exploring.
I was just curious if SQL could be used in the fashion I described.


Alan Shore

NBTY, Inc
(631) 244-2000 ext. 5019
AShore@xxxxxxxx

midrange-l-bounces@xxxxxxxxxxxx wrote on 12/20/2006 02:31:32 PM:

Alan,


I have a similar set-up.  Except that I refresh the Dev box

nightly.

don't use DDM or SQL, but simply SaveFiles FTP-ed.  Takes about 30
minutes for us (ymmv) to do that at 1:30 am.


Although I don't explode the libraries at that point, it would be a
simple matter to invoke a process (RUNRMTCMD) from Prod to do that.
Just be sure that, if you do that, the procedure in the RUNRMTCMD

isn't

the one that actually explodes the libraries but submits the real

one
to

the job queue on Dev, otherwise Prod will stay connected to Dev;

i.e.,

the Production process will be an active job until the remote

command

ends on Dev.


The problem that I have with automatically restoring the libraries

is

errors related to journals when I clear or delete the libraries

before

the restore.  Primarily, though, I don't want it to wipe out

"stuff"

I've been developing and testing.


   * Jerry C. Adams
*IBM System i5/iSeries Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
   615.995.7024
fax
   615.995.1201
email
   jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>



Alan Shore wrote:

Good morning list - Before I forget, or don't have a chance again,
A Merry Christmas and a Happy New Year to one and all.

We have 2 boxes, one for PRODUCTION, the other one for DEVELOPMENT
Each weekend, using DDM, we refresh the DEVELOPMENT data from the
PRODUCTION box.
The past 3 weekends we have been having problems where one of the

files

has

not finished till late Monday/early Tuesday. This has resulted in

cleanup

of this file deleting some records that shouldn't be there

otherwise
we

have problems on the DEVELOPMENT box when we try and test any new

changes

to the ORDER ENTRY system.
My question is
can SQL be used to directly create files ON the DEVELOPMENT box

from
the

same name files ON the PRODUCTION box?
If so, does anyone have any examples of what is required?


Thanks in advance



Alan Shore

NBTY, Inc
(631) 244-2000 ext. 5019
AShore@xxxxxxxx


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

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


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

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


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