Re: Storing and Reusing Statements from STRSQL

>At 09:58 PM 4/10/99 -0700, you wrote:
>
>Kirk,
>
>Although I do not actively use SQL, when you exit an SQL session, the
>system asks you if you want to save your work.  The default is "yes".
>
>It is unclear to me where this info is saved, or if you can even port it
>from system to system.  My suspicions are that this data is either kept in
>the "interactive portion" of your *USRPRF, or in some file in QUSRSYS.
>
>Al



Note: this information may be out of date, but this is how it used to work
(IE it bit me once):

Session information is stored in 1 of 2 ways:  If your user profile always
uses SQL from one and only one workstation session, your saved session is
always the one you saved.

If you ever use SQL from more than one session at a time, you get 2 saved
sessions, one for each session/device name.

Evidently, the system saves a single saved session until you try and be in
2 places at once, at which time it differentiates between your multiple
personalities.

It's annoying if you have some 'favorite' statements saved, and can't get
back to the other session to find your defaults.

I don't know if things have changed; I try to only use SQL from one place
at a time, just in case.

Of course, saving your 'favorite' SQL statements in a PDM/SEU source member
is possible.


>>If I type a SQL from a STRSQL session how can I save it, and make it runable
>>from a cmdline or cl?

If you copy / paste your SQL statement to a source member in PDM/SEU, you
can use the RUNSQLSTM command to execute the SQL statement as part of a CL
program, or from a command line.

Some things to note:  You can have multiple SQL statements in a single
source member, but each line must end with a semi-colon   (;).   You may
need to make a LONG source member; I don't recall if you can wrap a
statement from line to line.

When you run the RUNSQLSTM command there is a parameter for Commitment
Control.  Unless you're a glutton of long-running things, just say *NO.
Otherwise, your SQL statement will be run under commitment control, and
your SQL transaction will roll back if it has problems.  If you're updating
every record of a large file, this could take a while and tie up the file.

Saying *NO, however, means that your SQL statement had -BETTER- be right!
Test it first!!


--Paul E Musselman
PaulMmn@ix.netcom.com


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---