Printable View
Since SQL is very powerful is there an easy way to simulate whatif(s)
if such SQL commands are ran against a PF. My current work around to
this is copying files and then evaluating my results, I did not know
if there is an easiear way to do this. I have used the apyjrnchg
command and rmvjrnchg command to move records back etc but did not
know if there is a quick and easy way to do this, thanks.
il 17/10/2008 13.43, Scrive iseriesflorida 43711712:[color=blue]
> Since SQL is very powerful is there an easy way to simulate whatif(s)
> if such SQL commands are ran against a PF. My current work around to
> this is copying files and then evaluating my results, I did not know
> if there is an easiear way to do this. I have used the apyjrnchg
> command and rmvjrnchg command to move records back etc but did not
> know if there is a quick and easy way to do this, thanks.
>[/color]
You can do with interactive SQL. Look at the help (pressing F1) of
parameter PROCESS of STRSQL command, or changing the same SQL session
attribute from inside STRSQL (pressing F13 + 1)
--
Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñejoAlcoolInside
Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'
On Oct 17, 12:43*pm, iseriesflorida <iseriesflor...@yahoo.com> wrote:[color=blue]
> Since SQL is very powerful is there an easy way to simulate whatif(s)
> if such SQL commands are ran against a PF. *My current work around to
> this is copying files and then evaluating my results, I did not know
> if there is an easiear way to do this. *I have used the apyjrnchg
> command and rmvjrnchg command to move records back etc but did not
> know if there is a quick and easy way to do this, thanks.[/color]
Do you mean you would like to see how many records would be inserted/
updated/deleted ?
If so then changing the statement to a select would be the best way.
The next best & possibly quite poor is to ensure all your files are
journalled & start an sql transaction eg SET TRANSACTION ISOLATION
LEVEL READ UNCOMMITTED
then rollback when you are done. This has the downside that other
processes can see your uncommitted chnages & possibly make decisions
based on them. The other downside is that the rollback is actually a
reverse update so it makes the physical changes again wheras commit is
quite a quick operation (apparently) STRSQL can prompt set transaction
for you. There is also the option to set COMMIT from the STRSQL
command or F13 option 1 & I am unsure as to the reason for this as it
dosnt make sql hold locks on inserted rows.
If you call stored procedures or have triggers you might find an
extraaneous commit or rollback which fouls up this testing.
Jonathan.