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" <[email protected]> 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" <[email protected]> > > 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
