OIC, then I agree with you. :-) Got a new computer for Christmas with Win 8 ( upgraded to 8.1 ) and the UI is about as bad as they get ... IMO.

Thanks for the info and I finally resolved the issue from you post and a post from another on SQL Central.com. As noted SSMS weas "defaulting" the mdf/ldf files to the ones it "knew". Changing the file references to the 2012 locations resolved the issue ... which highlights another issue I don't like that sometimes MS tries to be a little too smart/clever/all knowing w/o notifying the User as to what they are doing. I.e. in this case if i say restore DB XYZ, then default to pointing to the files of the restore object DB, not the one it "knows".

Ok enough of ranting about things out of my control. :-) Just sometimes therapeutic to say what feeling.

To all, thanks for the feedback and help.

Bill

>>The reference wasn't a lot of specific help but I will check the permissions thingy. But I do agree with his peroration.
>
>That's my blog :).
>
>> I really do not care for MS, but I'm constrained to work on their platforms. Generally MS stuff seems pretty poor to me ( e.g. Win 8 ).
>>
>>Well, enough of complaining. What I do find interesting after looking carefully at the error message is the reference to the DB being in the 2009R2 "domain". I'm trying to restore a 2008R2 DB Backup ( XXX.bak ) file to a 2012 DB. But SSMS seems to be pointing to the 2008R2 DB mdf??? Don't really understand this.
>
>The original path is probably stored somewhere in the backup, so it defaults to it, but that location belongs to 2008R2 - which may actually have the db open (which would explain the "access denied" in the message).
>
>Just grab the restore script, paste it in an editor window, change the folder and run it. You may get a different error message (knowing that SSMS generated scripts generally need some tweaking), but in the end this should work.