Hi Steve,

This is a bug. It is APAR IC60568.
It will be in the next Data Protection for SQL PTF (5.5.3).
The target is October/November.

Thanks,

Del

----------------------------------------------------

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 08/25/2009
09:39:06 AM:

> [image removed]
>
> surprising behavior of TDP-SQL during gui restore of full/diff set
>
> Schaub, Steve
>
> to:
>
> ADSM-L
>
> 08/25/2009 09:40 AM
>
> Sent by:
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Please respond to "ADSM: Dist Stor Manager"
>
> Windows 2k3, SQL Server 2005, TDP 5.5.1.0
>
> We had a situation recently where a coworker used the gui to recover
> a SQL Server database, with some unexpected results.
> The database had a weekly full + hourly differential set, and he
> needed to restore it to an alternate name/location.  Selecting the
> diff version correctly selected the corresponding full, which he
> right clicked on to fill in the "restore into" and "relocate" options.
> What seemed to happen when he clicked restore was that the full
> restored to the new db successfully, but the diff then tried to
> restore over the top of the existing production db.  Through some
> trial and error we discovered that the gui requires the "restore
> into" and "relocate" to be specified on both the full and the diff
> in order to work correctly.
>
> Is this a planned design?  Because it has what I call a high
> "astonishment factor".  I would expect the gui to be smart enough to
> know that the full and diff are tied together and if I specify a
> relocate, it applies to both.  This obviously caused us some issues,
> as it attempted to write back over the top of a production database.
>
> Steve Schaub
> Systems Engineer, Windows
> BlueCross BlueShield of Tennessee
>
>
> -----------------------------------------------------
> Please see the following link for the BlueCross BlueShield of
> Tennessee E-mail disclaimer:  http://www.bcbst.com/email_disclaimer.shtm