Comments
Sort by recent activity
petey2 said:
Have you tried creating the folders (F:\hoit001 and G:\hoit001) and running the restore again?
Well, I have to do this all via tsql and as far as I know I can't create a folder in tsql without adding permissions to shell, which I don't want to do for security reasons. So it really doesn't matter if it works when someone manually creates the folders, we need this to be a hands-off automated process. To give some context, the end goal here is fixing an issue we have with a required middle of the day restore. During the restore, users can't access the data. So the idea here is do the restore under a different name so the main db is up and accessible the whole time. Then when the restore is complete, we flip the users to the new db by taking down the old one and renaming the new one before bringing it on-line. In that way, we go from a db that's down for 60 to 90 minutes to one that down 5 or less minutes. / comments
petey2 said:
Have you tried creating the folders (F:\hoit001 and G:\hoit001) and running the restore again?
Well, I have to do this all via tsql and as far as I know I can't create a folder ...
No, the original HOIT files are in other folders. They are on G and F but different folder names than the script. / comments
No, the original HOIT files are in other folders. They are on G and F but different folder names than the script.
petey2 said:
Do the target folders (F:\hoit001 and G:\hoit001) already exist? Neither SQL Backup nor SQL Server will automatically create the target MOVE folders, you will need to create them manually prior to running the restore.
No, the folders don't exist. SQL Sever's MOVE will not create a folder that doesn't exist? I recall doing that before with a tsql RESTORE, not with RedGate. The only issue I've seen was using a login without permission to restore, I do have restore permission. That's why this is odd for me. / comments
petey2 said:
Do the target folders (F:\hoit001 and G:\hoit001) already exist? Neither SQL Backup nor SQL Server will automatically create the target MOVE folders, you will need to create the...
The error turned out to be a permission problem. When restoring this db, the user set as owner of the db didn't exist on the new server. So the owner was blank. Once I set that to the same user that was running the restore, in this case the one running the job, then the restore worked.
Of course, what I was doing to "disable/enable" replication is not right (it's way more complex than what I have). I found that to make that work I have to delete replication, do the restore, and recreate replication. Lucky for me, this can all be done via t-sql. Lots and lots of t-sql but it's doable.
I'm all sorted out now.
Thanks Rick, have a good one. / comments
The error turned out to be a permission problem. When restoring this db, the user set as owner of the db didn't exist on the new server. So the owner was blank. Once I set that to the same user ...