Another option would be don’t remove the tables. Only remove the data and leave the tables alone. Since I assume you do all your development work in dev, then move the changes into production the schemas should be identical. All you should need to do is download the data for the tables that your application writes to. All the read only tables can stay the same.

If you need to drop and recreate all the tables each time you can use the scripts found here to get the rights from production as a T/SQL script you can then run against the dev database. If the usernames aren’t the same a quick search and replace will take care of that.

Another gripe I have with ss2008 and SSMS is the nightmare it has made of permissions. When I set up a new table on my development server with ss2k I could set its permissions, get it all working and then upload it, preserving all its permissions. As long as you had the same logins on both servers, it worked fine.

As far as I can see SSMS doesn’t do this, so each time I back up my remote db onto my local one, I ‘lose’ all the permissions and have to then go and set every permission on the local server again. And given the number of different restricted access logins I have for different web pages, that’s a big job. Is there any way of preserving permissions on tables to stop this happening?

Thanks again for your help.