We are having spare SQL user call licenses for Release 2005, Can we reuse this user call licenses for Lower release of SQL server2000.
View Complete Post
We purchased a company about 2 years ago, we have a SQL Standard box with the CD's and Product Key.
How can we find out if this is a per server licenses or cal's (per user)
We have a slow-performing query and, after some analysis, have narrowed the cause down to using parametrized queries in conjunction with LIKE and aggregate comparisons used in the WHERE clause. If we use a non-parametrized query (but keep the WHERE
clause the same) the query performs much faster and, in fact, executes a different plan. Using OPTIMIZE FOR UNKNOWN is not an option for us as we are using SQL Server 2005. Obviously, we'd like to use parametrized queries to prevent SQL injection
but the slow perf is unacceptable. We need the LIKE to support wildcard scenarios. If we need to we'll use dynamic SQL (scrubbed as much as we can) in lieu of parametrized queries. We're wondering, however, is there another option that would
give us the perf without sacrificing safety? I can provide a sample database, query, plans, etc. if necessary...I'm assuming SQL Server generates a less efficient plan with the parametrized query as it can't make any assumptions about the parameter values...
I have MS Accounting Professional 2009 installed on Windows Small Business Server 2008 with the accounting database in SQL Server 2005
I can access the database on the server using my client installation of MS Accounting and use it as expected
When I add another user I am unable to restrict the access rights of that user by selecting a role for them and restricting their access by denying them access to certain areas or providing read-only access to certain areas
What happens when we select a user and select a role and un-tick the Administrator rights box and click ok is that the user rights are not saved without administrator rights. When the user's rights are opened again, the Administrator box has a tick
in it again.
The sequence of events is exactly as described - untick the Administrator box, click ok, then select the user in the "Manage Users" list again, click "Edit" and there's a tick in the "Administrator" box.
In every other respect, MS Accounting appears to work ok, i.e. no error messages, no crashes.
We believe that we should be able to work around this issue by manually setting user access rights directly in the SQL database, but so far we have not been able to do that.
Has anyone ever experienced anything like this, can anyone provide any help or suggestions?
I'm trying to determine the minimal amount of access I can give my developers to be able to run create stored procedure scripts with an inclusion of the grant execute to the application user group.
We have been developing some interesting work arounds, but I think there must be an easier way to grant the access.
Grant Create Stored Procedure to user1 on a specific database
Grant Permission to Grant Execute permission for Stored Procedures on a specific Database to user1 for any user.
I have to restrict users from droping & truncting on table's
so how i will achive it,