Restore..why?

[Raquel]

Had a simple question..there is a command in UDB:
RESTORE DB a TAKEN AT ts1 INTO b
Where 'a' is one database, 'b' is another database and ts1 is a
timestamp in the past when database 'a' was backed up.

Seems that with this command, UDB 'overlays' database 'b' with the
contents of backup copy of database 'a' (I know that is a simplistic
way of putting it).

My question is: What are the scenarios when someone would give this
RESTORE command? Why would anyone ever want to 'overlay' a database
with another database?

[Gert van der Kooij]

Re: Restore..why?

In article <9a73b58d.03121 02258.87690ab@p osting.google.c om>,
raquel_rodrigue zus@yahoo.com says...[color=blue]
> Had a simple question..there is a command in UDB:
> RESTORE DB a TAKEN AT ts1 INTO b
> Where 'a' is one database, 'b' is another database and ts1 is a
> timestamp in the past when database 'a' was backed up.
>
> Seems that with this command, UDB 'overlays' database 'b' with the
> contents of backup copy of database 'a' (I know that is a simplistic
> way of putting it).
>
> My question is: What are the scenarios when someone would give this
> RESTORE command? Why would anyone ever want to 'overlay' a database
> with another database?
>[/color]

I do know several scenarios:

- we are working with several developers and each developer is using
his own database. If one of us has filled his database with valuable
test-data he creates a backup of his database and any other developer
can use this backup image to get the same test-data

- when a problem is reported in one of the production databases we
sometimes need that production database on our development network to
debug and trace the problem so we restore it into our own database

Almost all the time a drop database and a restore database (without
into) would have worked also but when specifying the INTO option
together with the REPLACE EXISTING the restore always works without
additional prompting etc..