Post reply

RESTORE behavior with MOVE command

  • June 25, 2016 at 8:05 am

    #400321

    Running SQL Server 2014 SP1 on Windows 2012 R2

    We do a lot of automated restores in lower environments from production every evening. The drive layouts vary from server to server. I've noticed that, occasionally, a restore will fail because it can't find drive "x:". Re-running the restore with the MOVE clause does the trick. What's odd is that subsequent runs of the command without the MOVE command work.

    Does SQL Server somehow "remember" how to map the drives after an initial restore run with the MOVE command?

  • June 25, 2016 at 12:45 pm

    #1886911

    2josephpkeating (6/25/2016)

    Running SQL Server 2014 SP1 on Windows 2012 R2

    We do a lot of automated restores in lower environments from production every evening. The drive layouts vary from server to server. I've noticed that, occasionally, a restore will fail because it can't find drive "x:". Re-running the restore with the MOVE clause does the trick. What's odd is that subsequent runs of the command without the MOVE command work.

    Does SQL Server somehow "remember" how to map the drives after an initial restore run with the MOVE command?

    If you're not dropping the target database first and you're using REPLACE as a restore option then, yes, SQL Server will do a restore by name quite nicely without the need for a MOVE command.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply