How do I set a SQL server connection to readonly? I tried Googling and all I found was File Mode=Read Only, but it didn't work (File Mode keyword not supported). The reference looked SQL CE specific.
No luck with SQLite Read Only=True either.
-edit-
My connection string is below. I have no clue when it comes to configuring the tables. I don't know how to make users/permissions.
rdconn = new SqlConnection(#"(wrong)Read Only=True;Server=.\SQLExpress;AttachDbFilename=test2.mdf;Database=dbo;Integrated Security=SSPI;User Instance=True;");
Just set on current user's permissions to SELECT only.
Is that what you want?
Click on the current db in SQL Server Management Studio, after click on Security->Users. Find your user, right click on him -> properties->Securable. Just mark SELECT, unmark all others.
Here're links on managing permissions
http://www.databasejournal.com/features/mssql/article.php/2246271/Managing-Users-Permissions-on-SQL-Server.htm
http://www.mssqlcity.com/Articles/Adm/manage_users_permissions.htm
Just found a a free tool for managing permissions. It can be useful too. Check the link
http://www.idera.com/Products/Free-Tools/SQL-permissions/
UPDATE:
If you want the DB to be read-only to any user:
ALTER DATABASE database-name SET READ_ONLY
or read here for more information
http://www.sqlservercurry.com/2009/03/set-database-to-read-only-mode-using.html
http://www.blackwasp.co.uk/SQLReadOnly.aspx
Change the security settings for the used login in SQL server.
For instance only db_datareader.
It's really simple.
If your db-user is called
MyApplicationWebServices_EN
Create a new login called MyApplicationWebServicesReadOnly_EN, with default language English (or whatever you need), who is member of the server-role "public" only (default).
In the DB you want the user to have access to, create a new user called MyApplicationWebServicesReadOnly_EN, and map it to login MyApplicationWebServicesReadOnly_EN.
Right-click the user in the database, and select properties -> general
In the Select-box list for "Membership in database roles", select db_datareader only (make sure all others options are unchecked).
Now use MyApplicationWebServicesReadOnly_EN in your connection string as "user id", and you have your read-only mode..
Of course, if your entire db should be read-only, then
ALTER DATABASE your_database_name SET READ_ONLY
will do just fine, as hgulyan said.
If you want to access the database in readonly mode, you can create a user for database and can enable 'READ' rights and disable 'WRITE' rights
you can see the users under database in sqlserver select that and if you want you can create new user else you can set the rights in properties
Also refer
http://www.zimbio.com/SQL/articles/-jf4iDK7qWQ/Set+database+read+only+mode+using+SQL+Server
In some cases, for instance in a High Availability instance in Azure, you may have a read-only replicated duplicate of your database. In that case, you add
;applicationintent=readonly
to the connection string to have that user reach the Read-Only replica.
More at Microsoft...
Related
I have backup from production database, which I restore on my local computer.
But when I try to create diagram, I have got message where is noticed problem with authorization. Ok, I went to change database owner, right click on database, option Files, and I have noticed that owner field is empty.
Why is it empty?
This is most likely because the login that was set as the owner on the production server doesn't exist on the server you restored it to.
You can recreate this by creating a login, say "test_user", creating a database and making "test_user" the owner.
Backup the database, delete it, then delete the "test_user" login.
Restore the database you deleted, the owner will now be blank.
I had this issue then realised that it would be affecting quite a few databases so i needed some way of finding which databases were affected - using the latest SQL SSMS 17 I found that if I was the person who had restored the database that the usual suggestions of sp_helpdb etc. don't work as they fill in the owner name with your own username, yet the "owner" field is still empty in the files tab of the database properties.
I used the SQL Profiler and found that it uses:
use MyDatabaseThatsMissingItsOwner;
select suser_sname((select sid from sys.database_principals where name = N'dbo'));
to populate that field, and bingo, that will indeed return a null string if the originally owner is missing.
I want a way to write my own query to restore the database. The database to restore needs to have all the settings to delete the current user and re-map the same user. The reason for that is because when the database is restored, the user will not have the right settings to use the database and will have to re assign the user the privileges.
Check this out:-
Step 1: Retrive the Logical file name of the database from backup.
RESTORE FILELISTONLY
FROM DISK = 'D:BackUpYourBaackUpFile.bak'
GO
Step 2: Use the values in the LogicalName Column in following Step.
----Make Database to single user Mode
ALTER DATABASE YourDB
SET SINGLE_USER WITH
ROLLBACK IMMEDIATE
----Restore Database
RESTORE DATABASE YourDB
FROM DISK = 'D:BackUpYourBaackUpFile.bak'
WITH MOVE 'YourMDFLogicalName' TO 'D:DataYourMDFFile.mdf',
MOVE 'YourLDFLogicalName' TO 'D:DataYourLDFFile.ldf'
/If there is no error in statement before database will be in multiuser
mode.
If error occurs please execute following command it will convert
database in multi user./
ALTER DATABASE YourDB SET MULTI_USER
GO
The reason for that is because when the database is restored, the user will not have the right settings to use the database and will have to re assign the user the privileges.
I guess that:
You are using mixed mode authentication and the user is a SQL Server user (not a Windows user)
You are restoring the database to a different server than the one where the backup was made
Correct?
If yes, you need to consider the following:
The user must exist on the second server as well, it's not created automatically when you restore the database there
It's not enough to just create a new user with the same name on the second server - to SQL Server, this would be a different user!
I guess that the second point is the reason why your user doesn't have "the right settings" after restoring.
Some background:
Internally, all SQL Server users are represented by a SID (something unique and unreadable - similar to a GUID. SQL Server doesn't care about the actual user name internally).
The permissions that each user has on a database are saved inside the database, using the SID and not the username
When you restore the database to a different server, the permissions are restored with the database...but they only work when there's a user with the exact SID on the new server
As I said before: when you just create a new user with the same name, he gets a new SID.
So what probably happened is this:
on the old server, there's a user "Mohammed Tahir" with the SID 123456789
inside the database, there's a permission that says "SID 123456789 is allowed to read from this database"
you restored the database on the new server
you created a user "Mohammed Tahir" on the new server, but he has a different SID (let's say 987654321), so the existing permissions on 123456789 don't work for him!
So what you need is a way to "copy" the user from the old server to the new server, with the exact same SID.
There is a stored procedure from Microsoft named sp_help_revlogin, which does just that.
It generates a script with all the users from the old server. You can then run the script on the new server, and it will create the users with the same SIDs they had on the old server.
Then, you can restore the database from the old server to the new server, and all the permissions already in the database just work.
You can get sp_help_revlogin from this MSDN article:
How to transfer logins and passwords between instances of SQL Server.
Note that there is nothing special about the actual restoring process - it's the users and their SIDs that make the difference.
So you don't need any "special" commands to restore the database, just the standard ones, for example the one from Rahul Tripathi's answer.
SQL Server is not my strong point and I start to get lost when going past the basic Create Table, Select from Table etc.
I am attempting to set up a database synchronisation scenario with an Microsoft SQLCompact 3.5 database being Synced through a Proxy to and SQL 2008 R2 database. It is being synced through the Microsoft Sync Framework 2.1.
I got everything set up and working fine through the proxy when the user account is the db_owner of the database.
Of course this now needs to be locked down - so I have been trying to restrict the permissions to the bare minimum required for Synchronisation.
According to the Microsoft articles, I need to do the following...
Use the principle of least permission. Do not grant more permissions than are required to perform a specific task. For example, do not grant INSERT permissions for server database tables that are involved in download-only synchronization. Synchronization operations require the following permissions:
EXECUTE permissions on all the stored procedures that Sync Framework uses to read and write to metadata tables and base tables.
SELECT, INSERT, UPDATE, and DELETE permissions for metadata tables and any base tables that will be updated during a synchronization session.
When you provision SQL Server databases that use SqlSyncProvider, be aware of the following permissions requirements for provisioning:
CREATE TABLE permissions to enable creation of the metadata tables: scope_info and scope_config, and the tracking tables that are created for each base table.
ALTER TABLE to add triggers to the base tables.
CREATE PROCEDURE permissions to create the procedures that Sync Framework requires.
SELECT and INSERT permissions for scope_info and scope_config tables.
SELECT permissions for base tables.
I allowed the wizards in Visual Studio 2010 to create the Sync database and proxy for me.
As such - I am unable to find the scope_info and scope_config tables in SQL Server databases, and I am also unable to find the metadata tables so cannot set permissions on these tables. Also - where would I find the stored procedures that the Synchronisation framework is trying to use - I have looked but cannto find them.
Where would I find these and how would I go about setting the appropriate permissions?
I have granted datareader and datawriter, Insert, Update, Delete and Select as well as Execute permissions on the SQL Server database but the sync fails. I have also granted Create Table, Create Procedure and ALTER permissions on the database for the user as well- but still it fails.
If i enable the db_owner role for the user - it works.
The error I receive is:
Unable to initialize the client database, because the schema for table 'tblApplications, tblApplicationConfiguration, tblApplicationInstallProperties, tblApplicationPreRequisites, tblApplicationTypes, tblComputerApps, tblComputers, tblComputerTypes, tblDriveHWSerials, tblDrives, tblDriveTypes, tblFunctions, tblLocationApps, tblLocationComputers, tblLocationIPAddress, tblLocations, tblLocationUsers, tblPermissions, tblRegionLocations, tblRegions, tblRegisteredModules, tblRequestFormats, tblRequestStatus, tblRequestTypes, tblRoles, tblRoleUsers, tblSecurity, tblUsers, tblVehicle, tblVehicleLocationMap, tblVehicleMake, tblRequestProcessingStatus, tblDriveStatus, tblVideoViewTypes' could not be retrieved by the GetSchema() method of DbServerSyncProvider.
Make sure that you can establish a connection to the client database and that either the SelectIncrementalInsertsCommand property or the SelectIncrementalUpdatesCommand property of the SyncAdapter is specified correctly.
I am not able to use the db_owner role when its released.
there are two types of database providers in Sync Framework, the offline provider (SqlCeClientSyncProvider/DbServerSyncProvider) which is used by the Local Database Cache project item and the collaboration/peer-to-peer provider (SqlSyncProvider/SqlCeSyncProvider).
the offline providers dont use the scope_xxx tables as such you wont find it.
assuming you used the default SQL Server Change Tracking when you configured the sync via the wizard, try granting VIEW CHANGE TRACKING permission to the account you're using to connect to the database.
I'm not sure if it will help, but I found this:
Try to set UploadOnly on the SyncTable object instead. When you set it on the SyncAdapterBuidler, the select incremental commands are not generated by the builder. These commands are used to get the table schema from the database. Since these are missing you are getting the schema error.
Also, maybe this blog entry will help.
As JuneT Mentioned, you should turn on Change Tracking
ALTER DATABASE YourDataBaseName
SET CHANGE_TRACKING = ON
(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON)
In order to see all of the tables in our companies DB I have to go find the main sys account. Is there a way to default my connection so that it shows the other users tables?
Any table that your connecting account has at least SELECT privileges on will show up in the "Other Users" node of the navigation tree. If the table does not show up there then it is a database permissions issue, not a SQL Developer configuration issue.
Think you don't want to repeated type otheruser.tablename in all your queries. If that is the case you want to run this
alter session set current_schema = otheruser;
What do you mean by "see all of the tables"? Are you happy if you know they're there, or do you need to see their content. In the former case dba_tables should do. In the latter case it's a matter of the privileges assigned to you.
Change your connect to login as the main Sys user. Otherwise like dpbradley says you will have to go find them under the Other Users node.
If you connect to (e.g.) DB2 using JDBC driver, you can use this syntax:
jdbc:db2://localhost:50000/WESBDB:currentSchema=WESB;
Not only that the schema WESB will be your current schema, but it will be also the default schema in the tree on the Connections tab.
Note: It seems that it works for DB2 only.
As Ram, I also do it with
alter session set current_schema = otheruser;
It works if you want to access to the tables of a particular user
I'm attempting to load a dll into MSSQL with:
USE dbname
GO
CREATE ASSEMBLY foo
FROM 'C:\foo\foo.dll'
WITH PERMISSION_SET = UNSAFE
GO
And I'm getting an error that states:
Msg 33009, Level 16, State 2, Line 2
The database owner SID recorded in the master database differs from the database owner
SID recorded in database 'dbname'. You should correct this situation by resetting the
owner of database 'dbname' using the ALTER AUTHORIZATION statement.
MSDN really isn't telling me any more about the error than the error tells itself.
I've looked all over the internet and have come to the conclusion that only thing anyone has ever done to avoid this is to:
use dbname
go
EXEC dbo.sp_changedbowner #loginame = N'sa', #map = false
But is changing the owner really the only way to avoid this error? Why do I have to do this, is there another way? I'd like some more information about this error before I go in and blindly change the owner.
I have had exactly the same problem and only solution for me was to change the owner, then change it back again.
The problem is that users are both per-database and per-server. What's happened is that the per-database user has a username that is the same as a per-server user, however they SIDs don't match, so it thinks it could be a different person.
Something you might want to check: If the user that you are logged in as (and are creating the database as) is also mapped to the "model" database, then that user will be created under the users tab for the new database. This means that there are credentials under the Security tab for the instance AND for the local users for the database. To immediately solve the issue, drop the user from the local database - you can then set them back as the owner (from the instance credentials):
drop user [MyUser];
exec sp_changedbowner [MyUser]
To solve this problem long term, unmap the user from the "model" database (Security/Logins/[MyUser] Properties - User Mapping).