Note: This issue and the graphics below are best viewed by an outlook email transport as opposed to the Yahoo.com email service.
There are many tables explanations associated with the graphics to the right to review. Hopefully all the detail needed to see the problem has been included.
In Toad-5.6 there were several accept issue concerning database restore and the handling of the Logical and Restore as file location.
The current code in 5.7 beta doesn’t solve the problem but exacerbates the restore to another set of problems.
There are new buttons for backup which will be explored during the Beta process, but my concern here is that that the Toad-SS-5.7 code has taken the reported problems and attempted to resolve the accepted issues but now has continued down a path that is not usable by the user community.
I hope the below “To the Point” distinction suffices. If needed please get with Gita in support about the original submissions on Restore concerning Toad-SS 5.6.
Lastly, I would like to work with the developer directly on these backup and restore issues and get what I believe would be a more satisfactory set of toad code in these area.
Senior Systems, Database/Data Warehouse Architect
678.414.0090 my cell Primary
Toad SS 5.7
When you change the Database name on a Restore in Toad SS- 5.6 the restore of GCMA as GCMA_DBA(Empty), populates the Restore as File location.
Toad-SS 5.7 Does nothing correct. So I have to manually make the change to give the following results.
/* The below is not system generated but a combo of generation and manual correction */
RESTORE DATABASE [GCMA_DBA(Empty)] FROM
DISK = N'T:\Hank(DBA)\Keepers\GCMA(for FV_Load_(Purged)_Before_FKeyFix)_13-Apr-2012(2).bak'
WITH FILE = 1 ,
--- This is the incorrect code generated by the restore wizard.
--MOVE N'GCMA_Data' TO N'F:\MSSQL\GCMATM_B1\Data\GCMA_DBA(Empty)_1.mdf' ,
--MOVE N'GCMA_Data2' TO N'F:\MSSQL\GCMATM_B1\Data\GCMA_DBA(Empty)_2.ndf' ,
--MOVE N'GCMA_Data3' TO N'F:\MSSQL\GCMATM_B1\Data\GCMA_DBA(Empty)_3.ndf' ,
--MOVE N'GCMA_Log4' TO N'G:\MSSQL\GCMATM_B1\LOGS\GCMA_DBA(Empty)_4.ldf' ,
-- This is the operational code I created after the wizard made the above.
MOVE N'GCMA_Data' TO N'L:\MSSQL\GCMATM_B1\Data\GCMA_DBA(Empty)_1.mdf' ,
MOVE N'GCMA_Data2' TO N'L:\MSSQL\GCMATM_B1\Data\GCMA_DBA(Empty)_2.ndf' ,
MOVE N'GCMA_Data3' TO N'L:\MSSQL\GCMATM_B1\Data\GCMA_DBA(Empty)_3.ndf' ,
MOVE N'GCMA_Log4' TO N'K:\MSSQL\GCMATM_B1\LOGS\GCMA_DBA(Empty)_4.ldf' ,
STATS = 10
Here is the code generated by Toad-SS 5.7 where I have change the To database Name and Toad does nothing to change the Restore as file. If I performed the script there real GCMA database may be compromised.
Here is where I have cut and paste the new database name into the mdf, ndf and ldf … It looks real good until you get to step #5,
After step #5, all the drive locations go back to F:\ and G:\ which is not what should be generated.
This too will generate an undesirable response if the script or wizard is run, the underlying database file can get associated with the wrong database name or at best the script and wizard fail if the files are in use…
Lastly, I have included the script I use to validate the database file locations the sp_helpfile should be already understood
name AS [Logical Name] ,
physical_name AS [DB File Path] ,
type_desc AS [File Type] ,
state_desc AS [State]
WHERE database_id = DB_ID ( N'GCMA_DBA(Empty)' ) order by 1