We are developing an application to do a "hearbeat" test of all our SQL servers (2000, 2005 and 2008), and we're trying to figure out the minimum permissions necessary on the SQL server to do that. (Platform involved is TBD, but should use a standard connection string).
We are considering using a "SELECT ##VERSION" query, which should be all that is necessary to determine that the sql server is up and running and responding to requests.
What are the minimum SQL permissions necessary to simply connect to the server with a connection string? (We don't even want to give DataReader, if at all possible) Will those minimum permissions allow me to do the above query? Is there a better/more standard technique for doing this? Will SQL 2000, 2005 and 2008 behave differently?
Just create the login used by the monitor code. On SQL Server 2005 and 2008, you'll also need GRANT CONNECT SQL TO (login), otherwise it's the same.
No other rights are needed for SELECT ##VERSION. The db_datareader you mention is within a database, not the server level.
SQLPing will detect an installation but not always tell you if it's running.
When do do run SELECT ##VERSION, make sure that you open and drop a connection. A connecion left open may still work even if the SQL Servr is not accepting new connections.
Consider SQLPing.
Quote: "SQLPing can be used to discover detailed information about the connectivity of SQL Server 2000 installations without authentication of any kind."
Or google for SQLPing yourself. I've seen several other utilities of the same name.
All that is required is a permission on the tempdb database. This database is guaranteed to be present across all servers and all versions.
This will also make sure that the audit requirements are met as you do not have to give access to any other database for the heartbeat check.
Related
I am facing server name problem in SQL Server 2012. When I click on configure distribution I get an error:
Unable to connect to server. Specify the actual server name.
I changed my server name and restarted the services but unable to connect through new server name.
Basically, I am doing this on local domain based server.
Kindly suggest a suitable solutions.
After you rename a SQL Server machine, you will also need to rename the SQL Server instance itself using:
sp_dropserver <old_name>;
GO
sp_addserver <new_name>, local;
GO
For more information, see Microsoft's article called Rename a Computer that Hosts a Stand-Alone Instance of SQL Server.
I think what your probably finding is that changing the Windows server hostname doesn't actually change the original SQL Server instance name which still gets used for certain services. Run the following on the DB engine:
SELECT ##SERVERNAME
You'll probably find a different value to what your expecting from the OS.
There isn't really a solution to this that I'm aware of without re-installing SQL Server on the newly named box.
Also be careful with names that exceed to the 15 character NetBIOS limit.
We recently moved a database from MS SQL Server 2000 to MS SQL Server 2008. Everything works as expected with our main .NET client application but we are having problems with a MS Access 2003 application which connects via ODBC. A System DSN is used to make the connection.
When the database was running on SQL Server 2000 the Access application would request a user name and password once when the program was first started. Now, with the database running on SQL Server 2008 a user name and password dialog is requested every time a different table is accessed I believe.
This behavior occurs when using either the user account we have used for years and it also occurs if I use the database system admin account ( I know this is bad practice, it was just a test. )
What do I need to reconfigure to return to the previous, desirable behavior where the user is only authenticated a single time?
You could look at using a "DSN-Less" connection to MS SQL, microsoft provide instructions here: http://support.microsoft.com/kb/892490
The relevant connection string can be found here: http://www.connectionstrings.com/sql-server-2008#p3
All this aside, JMK's question is important, the method above is for if you are having linked tables to the server present in your Access database, however when working with dedicated database server's I always advise using "ADO" connections rather than "DAO" as this will avail better performance (especially if you are running queries)
If it is just queries you need to run then consider either the ADO method or take a look at the "Pass through" queries option, this like ADO will have the server doing the work rather than the local machine and the performance will be greatly improved.
This wiki post outlines both a problem and a solution. I wanted to post this for others that may be having similar problems, as I couldn't find anything specifically to solve this problem elsewhere.
We recently upgraded our SQL Server 2000 database to SQL Server 2005. One of the databases on the server is a back-end to a MS Access database. The MS Access database uses pass-through queries, via DSN-less ODBC to connect to SQL Server.
An example of the DSN-less connection string is shown below:
ODBC; DRIVER=SQL Server;SERVER=servername;APP=Microsoft® Access (Pass Through
Query);DATABASE=databasename;Network=DBMSSOCN;ConnectionTimeout=20;
Trusted_Connection=Yes
After the upgrade, we found that users were unable to run the pass-through queries, and were getting the following error displayed :
ODBC -- connection to 'SQL Server
' failed
This initially appeared to be a permission issue, as elevating the priveledges of the SQL server logins to sysadmin server role alleviated the problem (but obviously this isn't a great solution).
After taking the logins back out of the sysadmin role we found that when connecting to SQL Server via Management Studio, the login could execute the stored procedures. The very same login could not from within MS Access. This pointed to something MS Access was doing while trying to execute the stored procedures - rather than a permission issue.
We ran a trace on the server using Profiler, and this showed up MS Access trying to execute the following command prior to stored proc execution:
DBCC TRACEON(208)
It appeared to fail at this command, prior to stored procedure execution. Research on the web showed that DBCC TRACEON(208) is equivalent to using 'SET QUOTED IDENTIFIERS ON' command, and that in SQL 2005 priveledges to run this DBCC command had been revoked.
After further research, we found references to MS Query having a similar problem, and that the APP component of the connection string should be changed from 'MS Query' to something else.
On a hunch, we changed our APP component of the ODBC connection string, and MS Access no longer tried executing DBCC TRACEON(208) prior to stored procedure execution.
After further testing, we tracked the problem down to the 'copyright' symbol included in the APP component :
APP=Microsoft® Access (Pass Through Query)
By removing the copyright symbol, all was well with the connection and the application worked as it had previously done on SQL 2000.
Hope this helps out anyone else having a similar problem.
Isn't that the registered trademark symbol?
I believe you hit on one of sql server 2005's defences against odbc based attacks. Since there isn't anything on the internet about it, it is likely something MS handled internally.
Our MS Access application with linked tables to SQL Server 2005 is slow when using Windows Authentication from Windows XP clients.
We've been running it successfully using SQL Server authentication, but now we want to move to Windows Authentication for better security control.
Setup:
Database server: Windows 2003 Server, SQL Server 2005 SP2
Client: Windows XP SP3, SQL Server ODBC driver v2000.85.1132.00
MS Access application: MS Access 2003
Connection string:
DRIVER=SQL Server;SERVER=[server name];Connect Timeout=300;Trusted Connection=True;APP=Microsoft Office 2003;WSID=[server name];DATABASE=[db name]
Only the TCP/IP network protocol is enabled on the server.
The slowness does not happen in these situations:
App on DB server, SQL Server Authentication
App on DB server, Windows Authentication
App on Windows XP client, SQL Server Authentication
SQL Server Management Studio on client, Windows Authentication - I did a small test with running 15 queries in SQL MS. This went fast and did not cause any logon/logoff events in the Security event log on the server.
I've analyzed the slowness using SQL Server Profiler and the event log on the server and it seems to come down to this:
The application runs a query
A new connection to SQL Server is opened (visible in SQL Server Profiler)
The identity of the user is verified (visible in the Security event log on the server, a logon/logoff event happens). This takes several hundreds of milliseconds.
The query runs on SQL Server
Results are returned to Access
This happens for every query. Some of the forms run +- 10 queries when showing a new record (updating sub forms, loading values for combo's etc). This results in very slow performance.
Of course setting up a new connection to SQL Server for every query isn't necessary, and reusing connections might solve the issue. I've been looking around for information on how to make sure Access/ODBC does proper connection pooling. I found these MS KB articles:
Frequently Asked Questions About ODBC Connection Pooling
How to Enable Connection Pooling in an ODBC Application
I've tried calling the SQLSetEnvAttr function from the main form of the Access application, but this didn't improve results.
Any help is greatly appreciated.
The first question I have is: are you running a domain controller? This may sound like a crazy question, but I just want to make sure. Although is less and less common, I've seen organizations run Windows networks with workgroups and "pass-through" authentication. The symptoms you describe are the same as would be observed on a network that is set up in this fashion.
Assuming you do have a proper domain set up, you must have a problem somewhere in the Named Pipes network stack. Named Pipes is the default protocol if you're using Windows authentication. It's not a bad idea to get to the bottom of this if you have the time, but if you just want to fix your performance problem, then I would force the TCP/IP protocol in your connection string:
DRIVER=SQL Server;SERVER=tcp:[server name];Connect Timeout=300;Trusted Connection=True;APP=Microsoft Office 2003;WSID=[server name];DATABASE=[db name]
Note the addition of the tcp: prefix. I got this syntax from Jon Galloway's blog. TCP/IP is the default protocol for SQL Server Authentication. You can also make the protocol switch by disabling Named Pipes support on the server, but this is more of a hassle and could cause other unanticipated problems.
Check Microsoft SQL Server Native Client
at http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835cdc&displaylang=en
Here's my problem: I have an application which uses sql server express 2005, and it is installed under default sql server express instance, SQLExpress
Under this instance there are several other databases, used by other applications (web based or desktop)
If I need to restore the database, sometimes it works, but sometimes it fails, telling that I need exclusive access to database to do this. I understand that, and of course when I try to restore, the application using the db is closed, but probably it was just closed minutes before so sql server still keeps some connections open, for caching purpose.
And in this case I have two options:
restart the sql server instance -
that's easiest to do from user point
of view(right click on server
connection in Enterprise Manager and
select restart (but worst since this
stops all databases)
Detach my db, attach again then restore (this works because detach
have option to close all
connections). But this is harder to
do (takes more time) since I have to
browse through the folders to find
where db is located to attach back (I
keep all db's in a custom location,
not under default sql server database
location)
My question is, is there any other easier way to do this?
Thanks
In SQL server Management Studio (not sure about Express, I'll check) you can use the Activity Monitor under Management to locate any connections still open to the database. Right-click the connection and choose 'Kill'
This way you can clear any outstanding connections.
[EDIT] I've checked a SQL server Express, and it also contains the Activity Monitor.
Alternatively you can use a script to close all connections. See here for an example.