Re: How to copy an SQL table with a long name into the same library

Surely a *SAVF always helps ...

You can always do:

    RSTOBJ .... DEV(*SAVF) SAVF(xx/yyy) RSTLIB(QTEMP)  

for example, to just have temporary access to the data, e.g. for your "comparison" purposes.

Just saying ...





On Wednesday, November 3, 2021, 11:37:13 PM EDT, John Yeung <gallium.arsenide@xxxxxxxxx> wrote:





Re: Using a SAVF

On Wed, Nov 3, 2021 at 8:33 PM Rob Berendt <rob@xxxxxxxxx> wrote:

Thinking about that answer...
The OP was trying to copy an object into the same library
So, if you save X from LIBA and want to restore it as Y in LIBA how do you do that using that method?  I don't see how.
If you were restoring into a different library, maybe.  But this isn't the case.

The original statement of the problem was that the data should be
reverted back to its pretest state after the test is done. So there
doesn't need to be any Y in LIBA (or any other library).

If the problem had mentioned that they need both states to be
available simultaneously for comparison purposes, then I would say
yeah, the SAVF doesn't help. But I would also say that having Y in
LIBA isn't crucial. What we often do is have a library whose whole
purpose in life is to store "saved copies" of data, so the file name
can stay the same.

John Y.