![]() ![]() THAT FIXED IT! So, what have we learned today?ġ) Read the dadgum error message, it may actually tell you what’s wrong!Ģ) The TO FILE portion of a BACKUP MASTER KEY statement specifies the directory and file name of the file being backed up, instead of just the directory path to place the backup file. Note that a copy of the master key is also stored in the master database and encrypted by the Service Master Key (created at SQL setup), so SQL Server can. ![]() I chose to delete the directory since it was empty anyway. ![]() In this case, the solution was simple, all I had to do was either delete the “key” directory, or change the name of the file in my backup script (or change the path to put the file in the “key” directory). One would think that it could differentiate between the two, and create a file named the same as a directory, but one would be wrong. Still got the error.Īfter a good bit of Googling and getting nowhere, I took the time to actually read the error I was getting (which, you would think would be one of the first things I did!) As it turns out, the very first line of the error told me exactly with the problem was.ĭo you see the problem now? My backup script was trying to create a FILE named “key”, but I already had a DIRECTORY named “key” in that location. Just to see, I created new directories and modified my script and tried it again. So, maybe the folder permissions are not correct? I check permissions and everything looked good. So, I verified that the ‘C :\backup\key’ directories did exist, and that they were spelled correctly in my script. My first thought was: The directory path must be wrong. Verify that you have write permissions, that the file path is valid, and that the file does not already exist. When running that script, I was immediately greeted with the following error:Ĭannot write into file ‘C :\backup\key’.
0 Comments
Leave a Reply. |