Is there any other way to run tSQLt on a SQL Server database without sysadmin role or ALTER TRACE permission?
We are currently trying to use a test tool called SQLTest from Redgate which uses the tSQLt framework. We have installed it successfully on the database with the sysadmin role, but no one is able to use the tool apart from the person with the sysadmin role. Anyone else who tries gets an error message relating to permission.
I've been in touch with Redgate support and all they tell me is that the sysadmin role is needed or at least ALTER TRACE permission. These are elevated permissions and shouldn't be given to all users on a database.
Any help would be appreciated.
It is not clear exactly what your use case is but...
Typically, developers would use SQLTest and/or tSQLt on a local sandbox e.g. SQL Server Developer Edition installed on their laptops. If that is the case, most orgs should have no problems allowing developers to be sysadmin on their own locally installed SQL Server instance.
If you are using this on a shared SQL Server instance, again this should be a DEV environment where, hopefully SQL devs are allowed to administer their own dev environment.
I can't imagine any org allowing developers sysadmin access in a production instance but then you really shouldn't be using tSQLt in production anyway.
I might be wrong, but I believe it's only db_owner that's required to run tSQLt tests. Might depend on what procedures you're testing. Almost all of our tests are just data quality AssertTableEmpty tests.
If you have the Redgate Toolbelt (or SQL Compare, specifically), you should be able to create personal dev databases on the fly, make your changes, run the tests, then SQL Compare back to shared dev db.
There are two things at play here. tSQLt requires the executing principal to have permissions to alter any object in the database. Usually, you achieve that by making them part of the db_owner role.
Redgate SQLTest requires (in some circumstances) additional permissions. For example, the ALTER TRACE permission is needed to execute the code coverage tool that comes with SQLTest.
In addition to the above, there is a file called prepareserver.sql that needs to be executed once per SQL SERVER (not per database). It requires sysadmin privileges.
So, if you cannot use dedicated environments as #datacentricity recommended, you can execute tSQLt directly and not use SQLTest, or figure out which options to disable if you want to use SQLTest.
Like others here, I strongly recommend you use dedicated environments to do your development, independent of tSQLt.
Related
I developed an application that used SQL Server database 2017. I wrote most of the business logic in stored procedures, triggers & UDF. Now at the time of Go-Live, I want to deploy a compiled database on a client-server machine so no one can view or change scripts.
I can manage this from the SQL Security, access rights, etc. but actually, the Client network administrator has all the credentials and rights of the database and I do not want anyone to view/change the script even the administrator.
can I deploy a compiled database on a client-server instead of a regular one so no one can view/change scripts but can execute them Similarly like EXE file users can execute it but cannot view/change the code?
Does Microsoft SQL Server provide a solution on this or any workaround?
please suggest thanks in advance.
[Apologies, this may be a google-driving-failure; sure I've seen this documented somewhere, but I can't find it. I'm seeking a reference I can pass to colleagues.]
I am addressing the scenario of deploying multiple Project/WAR Runtimes to an MFP server environment, that environment using an Oracle database.
We see the documented requirement:
Each configuration for a MobileFirst runtime environment must use a
different runtime database or schema
And as for Oracle there is a one-one mapping from user to schema, in the WAR deployment instructions we see
For Oracle, the database user must be different.
The question here is about the privileges necessary for those Runtime users.
For the other schemas, used by the MFP server itself, there are table-creation scripts that are run during server-creation. Hence the DBAs can run those scripts, grant necessary privileges and at runtime the MFP servers users do not need capabilities such as table creation.
What privileges do these Runtime users need? I think they will at least need to create tables? Is there a point when it is safe to remove those privileges? That is, is there dynamic table creation?
The privileges the Runtime users need are listed in the documentation on the page that provide you manual installation steps for installing the Runtime
"Setting up your Oracle databases manually"
http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.deploy.doc/admin/t_setting_up_your_oracle_database_manually.html?lang=en
Those privileges are : CREATE SESSION, CREATE SEQUENCE, CREATE TABLE
There is no dynamic table creation.
The same privileges are used when you install Runtimes using Ant tasks or with the Server Configuration Tool.
Basically, it is not a good idea to remove the CREATE TABLE privilege for the user after the Runtime installation because you may run into trouble when performing an upgrade
to a new release in which one or more tables may have been added.
I used SQL Server 2008 R2 database in my application, now I want to install the application for my friend. How can I block access to my database tables and stored procedures ?
I removed Windows authentication and SQL Server Management Studio just login with my own user or pass ! But what happen if he opens my database file in other Management Studio in other systems?
Your users should not have access (ACL permissions) to MDF files, ever. Not at all. They should, instead, have database access, and their account should be set to do what you want them to do, and not to do what you don't.
This is a pretty basic question, really; what you need to look into is SQL Server security, so you can figure out how and what to secure your database with users. But you also need proper file security, as I noted above.
Finally... your question makes me wonder; you do know that SQL Server is not necessarily meant to be installed on every single client system, right? You certainly can do that, but it's a server product. If you are installing it on a computer to which the user has admin rights, the game is pretty much over, really.
I've been following Microsoft's guide for installing a dev environment on Windows 7:
http://msdn.microsoft.com/en-us/library/ee554869.aspx
In order for it to not run like a dog I've created a SQL Server 2008 instance on our database server specifically for this dev machine. The article does mention that you might be wanting to use an external database in regard to making sure the database cumulative update is installed. It doesn't make any other mention of configuring it to use a external database. I was hoping that the configuration wizard would then prompt about which database to use but annoyingly it just set-up the configuration database locally.
How do I go about installing SharePoint on a dev environment with an external database, and will I need to reformat this machine and do it all again?
Well, this depends on what your environment looks like. For instance, is this machine part of a domain?
If so, it should be as simple as selecting "Server Farm Install", or something like that when you did the binaries installation. Then, when you run Products and Configuration Wizard, it will ask you for DB info. Note: if you are doing this, I would recommend you to be part of the 'sa' role on the database server as you will be creating databases.
If you are not part of a domain, it gets a little trickier, but not too bad. Check out this article.
http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/Post.aspx?ID=112
-= Plan B =-
You can always give this a whirl. This is the method we use to keep the DB guys from screaming. It also allows us to give our databases nice names.
http://technet.microsoft.com/en-us/library/cc262869.aspx
I am using SQL Server 2008. I am confused about which account will be used when a SQL Server agent job runs. My confusions are,
SQL Server agent as a Windows Service which we could control from Windows Service Management Console, from there we could set the account to run SQL Server Agent (LocalSystem in my computer);
Could I set SQL Server agent job level account to run on?
Could I set in each step which account SQL Server agent job step will run on?
I have above confusions because 3 different account systems may be used and my concern is what is the actual account each step will run on, and I want to avoid any permisson issues (i.e. I want to make sure the account have enough permission.). Any comments or advice? Appreciate anyone could clarify the 3 levels of accounts, which makes me very confused.
thanks in advance,
George
I would typically run the SQL Server Agent jobs under the same account as your app accesses the database.
If that account is too limited in its permissions (which might be a good thing!), I would create a single account for that app and all its SQL jobs (if that's possible) and run all SQL jobs under that account.
You could potentially run each step under a different account, but I wouldn't use that in general (it just makes it really hard to know and understand what is run under which account). Only use it if you have to run a particularly sensitive step that needs a bunch of extra permissions and those permissions are only available to a particular system account or something.
The account under which the SQL Server Agent windows service runs really doesn't have an impact on what your job steps will be run under.
So it boils down to really just two accounts:
one account is needed to run the SQL Server Agent Windows service - this is a Windows account on your machine / server which needs to have enough permissions to run the service, start and stop it - either use LocalSystem, Network Service, or whatever other Windows account you have to run services with
The other account would be the account to run your SQL Server Agent steps under - that's typically a SQL Server account (which could be based on a Windows account), and it needs enough privileges inside SQL Server to do its job, e.g. it needs access to the database objects and all. I would strive to have just one account for each app that runs the SQL Server jobs - makes life a whole lot easier!
Marc
PS: To set the user to run a step under, you need to use the "Advanced" page on the Job step property dialog and select the user from a popup window:
You can create Credentials in SQL Server (use Mgt Studio, under Security). Then create a Proxy in SQL Agent to use those credentials, telling it what kind of job steps can be used by the proxy. Then you get the choice to use that Proxy in the job step itself.
So... I make accounts for various SSIS packages to run under, so that I can keep the SQL Agent Service Account low privilege, and use a proxied credential with slightly higher privilege (not admin though, just enough permission to connect to other systems, including the File System).
Rob