No as far as I can tell Recorder uses SQL server to manage the backup and the file generated is called NBNData.bak. The file is about the same size as the main database file and is generated pretty quickly, so I imagine the backup routine just detatches the database file from the server and makes a copy of it, before re-attaching it.

I'm not sure there even is a real permissions issue. We have only found one backup-related permission setting in SQL server, db_backupoperator and we have assigned this both to my login and to NBN_User. I know this works because I created the SQL server backup device, without this I was unable to generate the backup in the first place.

Interestingly if I try to restore while there is someone else logged in there is a long pause before I am told that the restore is not possible. If no-one else is logged in I get the "don't have permission" message immediately with no pause. It looks to me like when someone else is logged in the UI asks SQL server to restore and it refuses, while if no-one is logged in, the UI doesn't even bother to ask, just tells me I can't.

Assuming Recorder isn't doing anything fancy with the backup process... http://stackoverflow.com/questions/4908602/sql-server-2005-backup-restore-failing-with-folder-permissions says

Thanks Charlie

Not sure I really understand those lines you quote, but I told our ITC and he seemed to have a better understanding.

We'll see...

Didn't make any difference anyway....

I have tried restoring backups with SQL server tools, but haven't succeded so far (people keep loggin in - users eh?).

Ours is networked and the backup files are in a different folder, but there are no permission issues in that folder I am quite sure.

No I don't think so. The backup is managed by a "backup device", which is a SQL server object, not actually part of the database. This device specifies where the backup will go (path and filename). Normally this is created at install time and the backup probabaly goes into the default location you describe.

There is however an option (on the tools/database tools menu) to change the default backup location and we did this some time ago, when everything still worked, to put it in a more memorable location. As far as I know it worked fine after we moved it.

A couple of months ago we got a brand new server (and new SQL server) and everythying went horribly wrong for a bit as our old SQL server hive became corrupt during an attempted transfer and fell over, losing everything (we had backups).

Much tech support later the new SQL server works and the Recorder db also, except that in the transfer the backup device had been lost. No matter, it is the work of a few moments to create a new one and we have done so. But it won't restore anymore and I cannot change the backup location from within recorder either.

That's how I got to where I am now, I know rather more about SQL server than I really need to now.  But I have posted in the hope that someone whose job it is to trace and even fix problems like this will reply to my post (while there are still people being paid to do that). I would have thought that the thread above contains enough information to be able to track down what permission I do not have which I need.

No offence intended to you Charlie, or to the admins here who do a great job, but they have been noticeably quiet on this one, which is why I keep reposting.

Hi Rob so caught up in importing I had not thought I could help with your problem. Then I realised today that I may have the same issue. When I could not do the backup in the past I went ahead an did it in SQL Manager.

So now I'm wondering if any of my backups can be restored. I will attempt to have look at Mikes suggestion myself. It may be a while though.

Thanks Mike and John

Sorry about the slightly grumpy rant, but it served its purpose apparently.

Useful responses from both of you, but since I am away from the office for a few days I cannot check whether anyone else is logged in easily, so testing will have to wait until after hours.

Unfortunately John your summary of permissions doesn't help as both my login and the NBNUser have dbowner  already, but I still cannot do the restore. I will check whether the diskadmin role makes any difference to the ability to change the backup location anyway.

I repeat my conjecture that this is not (or not entirely) a permissions issue, it feels like a bug to me.

John, since you have access to the source code, would you be able to look for the message dialog I am receiving, which says  verbatim "Failed to backup database as you do not have permission" and find out under what circumstances it would be triggered by an attempt to restore (rather than create) a backup. It may of course be just sloppy programming and the message may have been recycled from an exception trap on the backup operation, if that is the case, then it should be easily corrected even if it doesn't help me with this problem. It seems to me that the dialog ought to report which permission is needed rather than just telling me I can't.

Mike, later tonight I will attempt to run the restore directly through Management Studio and see what error messages that delivers, if any.

Thanks to you both.

And Tony, who knows what horros await after the importing is done, watch this space.

Thanks John

We just arrived at the same conclusion. Sitting at home on my laptop I have a standalone install of Recorder which has server level roles as you describe dbcreator, diskadmin and public.

I have checked on the networked copy at work and it has no server-level roles assigned at all. Not all that surprising given that our setupwas transferred from one server to another as I described.

I can't make the changes from here but have requested them, I will post as soon as I have an answer.