On SQL Server 2008R2, we have a SQL login tagged with the sysadmin server role. Anytime a db is created, this login is automatically added as a user to the db. Is there a switch that will prevent this from happening?
EDIT:
Based on the answer below, I am adding more background info to explain why we want to do this.
When we publish to a new database from a Visual Studio SQL project, the publishing engine wants to add a user to the database. The username already exists as a login to the database (in the sysadmin server role -- and not much we can do about that), so the publish fails as the user gets auto-added by SQL server after the 'create database' statement. I was hoping for a switch that would tell SQL Server to not add the user automatically. So it seems we will have to find another solution on the VS side that tells the publishing engine to ignore the SQL DB user.
Assuming you're talking about the sql-server role, I don't think so. TBH if you're contemplating keeping a sys-admin out of a db, then you've got a different problem than the one you think you have...
I have a resolution to this. Download the latest SSDT package from MS and now there are new options under the Publishing Wizard Advanced... button to exclude the publishing of logins, roles, etc. The SSDT package I downloaded I found here...
https://msdn.microsoft.com/en-US/dn864412
Related
I'm writing a webtest in Visual Studio 2015. The webtest I currently have allows me to run a static test.
I would like to spice things up and therefore add more realistic data. The data I want to use is stored in an Oracle Database 12c.
So I'm trying to add a new Data Source to the webtest. I enter the TNSName, Username and Password for which I would like to connect and test the connection. The connection can be established, but the list with tables I can choose from is empty.
Connecting to the same Database using the "Server Explorer" in Visual Studio 2015 works. And using this method I do get the full list of Tables contained in that Database. I can even query any of the tables.
So how can I fix my webtest to have access to a specific database table (row)?
If you can connect to the DB but you don't see the needed tables it should be a permission issue.
Do you use same credentials from "VS->Server Explorer" to connect to the DB?
If this is not the case, do you have more than one Oracle clients installed in your system? If yes, then most probably, the DataSource control uses the wrong client and the "Server Explorer" the correct one.
Are you using synonyms as proxies for your tables (e.g. for permission reasons)? synonyms will not show up when querying the list of tables that the user can access. They need be queried separately. When only the available tables are queried but not the vendor specific aliases this might lead to an empty list.
You need to install ODAC for Visual Studio 2015 to view the database tables. Here is the link for it.
http://www.oracle.com/technetwork/topics/dotnet/downloads/odacmsidownload-2745497.html
i try to use Datagrip as my primary sql server query tools, bit i meet a problem that i can not move forward.
When i setup the project data source, i have to choose a Database, otherwise it will goto the default tempdb, how i can work like sql server management studio, that i can see all database list.
i have tried both jTds and Microsoft drivers, both not works.
or can i choose multi-database? i do not want to create one data source for one database.
if i connect to mysql, it works like expected.
tks
It is possible to connect without specifying the database. Just leave this field blank. After entering other settings (host, port, user, password), go to Schemas tab in Data Source properties and select all the Databases and schemas you want to work with. Then invoke Synchronize action for this Data Source in Database tool window.
DataGrip 2016.2 EAP claims to have support for showing multiple databases. See https://blog.jetbrains.com/datagrip/ and find for "Database View". Unfortunately, as of the date I'm writing this, it doesn't seem to work at all.
Unfortunately, Andrey's suggestion did not work for me.
I'm working on a Windows application. When I give this software to the client it is necessary to give database also? I want to lock the database of SQL Server on his computer so that he can not open that database or copy or view its schema or anything by which he can access that database.
When he tries to access that, it must ask for a password. So, what is the solution for the above?
SQL Server databases cannot be password-protected - they're not just files that get opened (like dBase or SQLite)
"normal" access control is handled via permissions and users - you can define who can see what, modify what, delete what
This does not however prevent a system admin from looking at your database schema and contents; there's really no way to prevent this, a sysadmin can also just copy the .mdf file to another server and attach it there and circumvent all your "security"
if you really must hide all of this, don't deliver a database - hide the database in your own company and provide a web-service based interface to the customer who can then call those web services to do his work - then the schema and data is under your control, but also: the customer's data is no longer under his control so he might not like that.....
I have an ASP.NET MVC 3 application using an Entity Framework (4.3.1) Code First database. Now I would like to create a comprehensive zip file containing the database, the application package generated by Visual Studio 2010 and a script to deploy everything to a Windows 2008 server with IIS7 and SQL Server 2008 with a prepared (but empty) database.
I don't foresee any problems with the deployment of the application package, but I'm unsure of what approach to use in deploying the database. The target environment already has an empty database that's been assigned to me, but I've been told that dropping and creating the database is fine.
From what I've read, I can do a straightforward copy of the .mdf and .ldf files to the server and then setup my connection string to point to that specific file but this approach sort of ignores the database that has already been created (or at least named) for me. The other approach would be to use the the existing .mdf to create the database on the server with a script. My only issue here is that I would like to keep the database name assigned to me.
I usually connect to my development database locally using SQL Management Studio and right-click the database, choose Tasks -> Generate Scripts. Then I select the entire database or just the tables I'd like to keep, click next, then click the Advanced button and make sure that I am scripting out "Schema and Data", and then generate a sql script that I can run on the production database, therefore keeping the table structure and the data that was in the dev database. Obviously, if you don't want to keep the data then just script out the Schema only. Then, point your application's connection string to the new production environment database and you're good to go.
We have restored an old ms CRM database over a newer version. But when I try and add users which were already existed in newer version I get an error.
If I delete the users from our of active directory and then try to add them to CRM it works fine.
Is it possible that CRM is storing user information in the MSCRM_CONFIG. And can this be removed in a supported way?
Have a look at the SystemUser in the MSCRM_CONFIG table, I think i need to remove the users from this table. but I can't do a delete statement as it's not supported. :)
Did you restore this database using the Deployment Manager tool or simply by doing a SQL Restore? Doing this directly from SQL would cause issues. You'll need to delete the organization in the deployment manager and then delete the database in SQL. Then you should attach the database and recreate the organization from the deployment manager, pointing it to the existing database.
Restoring just the org DB can lead to issues as some user info is stored in the config DB as well. In fact, there are entries in there mapping the user to the org (SystemUserOrganizations), so when you restore the Org DB, this mapping is now out of date.
You would need to either go the Delete/Import route or manually do some unsupported cleansing of the Config DB Tables.