When I attempt to connect to SQL server using enterprise manager I get the strange message:
"SQL Server is not known to be running. Are you sure you want to connect?"
What is it trying to tell me?
Is there some special caution required in trying to connect to a server that is not known to be running? If so, how do I find out if a server is running before trying to connect to it, and why doesn't enterprise manager provide this service?
It is simply telling you that it could not verify that the server is running and that a connection may fail in the eventuality that the server is down (or there is a firewall, or the network is down etc...).
You can simply click OK and let it continue.
See this post and this one for more detail.
Enterprise Manager communicates with each server instance on a background thread to determine its current state. You can see this happening on screen - the icon is blank at first, then changes to either green or red as appropriate when EM knows its state.
If you connect to a server instance when the icon is still white, then EM tells you that it hasn't had time to get the current state yet.
Personally I don't see the point of doing this, you will find out within a few seconds whether it's running or not anyway. :-)
Related
I am attempting to set up a communication between Labview and Microsoft SQL Server, on two separate devices, in order to send and receive information about the database from both labview to SQL Server and SQL Server to labview. However, when I reach the "Data Link Properties" menu, I get the same "unable to log in" error upon attempting to log into the server. The server name comes up, however, an error occurs once I move on to select the database on that server. Is there any solution or tutorial to this problem that can allow me to successfully communicate back and forth from labview and smss on separate devices?
I've opened up various ports to allow a connection, even disabled the firewalls on both devices. The devices are connected via an Ethernet cable and I AM able to ping the devices to each other. However, in regards to being unable to log into the server in ssms, I have created new users, adjusted the login properties, tried changing permissions, but anything I try doesn't seem to solve my issue.
Can't really help much without seeing the error or some of the code of what you are trying to do.
That being said, if you go to the menu and select Help>Find Examples... and search for database, you should see a bunch of different things related to database connections. You may find the Database Connection.vi one helpful.
More info on the Database Connectivity Toolkit in LabVIEW can be found here
I see there can be one of the 2 issues
1) Inbound/Outbound port rules not set, Remote connection to server is not allowed.
2) If the server has multiple instances then you need to provide full host name of the instance you are trying to connect.
*Please refer to the below link to configure firewall rules.
https://learn.microsoft.com/en-us/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access?view=sql-server-2017
up to a while ago I used SQL2k5 exclusively but recently got updated to 2008 R2. Apart from the obvious changes in Mgmt Studio, there is one quirk that's starting to be very annoying : each time a connection is dropped, I have to switch back to the 'lost' database again as it seems the conneciton automagically reconnected to the initial database again.
In SQL 2005 I simply had to press F5 twice and the first time it would give me an error saying the connection was lost, the second time it would reconnect to the database it was on before the connection got dropped and then execute whatever sql-commands it had. It did not really matter how I had gotten to that database, be it by using the dropdown-box on top, or a USE statement...
In SQL 2008 (R2) I now press F5 and mgmt studio will "eat" the lost connection silently and instead immediately reconnect to the server and execute the code on the default database or the database that I 'forced' while connecting using the [>> options] button/tabs
This happens quite a lot as I often have one tab open that kills all connections and restores the database, and another (series of) tab(s) with changed procedures, test-cases etc...
Is there some (hidden) configuration to (re)set this behaviour ???
I know I can try to add USE statements on top everywhere, or 'force' every connection directly to it's 'target' database, but bye bye for ad-hoc queries then =(
ps : doing some extra searching I'm wondering if this isn't due to the "fix" bespoken
here [connect.com]
ps: as a side note, after reconnecting the SPID on the bottom of the screen isn't updated properly either, as a result I've already been killing the wrong connection as I based myself on stale information ... yay for progress =( (**)
Anyone with better google-fu than me ? Or closer connections to Microsoft ? =)
Thx.
(**: man, I so miss Query Analyzer =)
If you register the instance you're connecting to in management studio, you can go to "Connection Properties" on the registered instance and set "Connect to database" to be the main database you use on that instance. When you are disconnected and it auto-reconnects, it will use that default database again.
Limitations:
You can only set this to one database per instance, by design.
You need to connect using that registered instance to get it to work (right click on it, then 'New Query'). If you just do a new connection without going to the Registered Servers pane, it won't apply the properties to the connection.
Certainly not a perfect solution, but perhaps better than nothing.
PS: Connect bug for incorrect spid is here. It looks like there is a promised fix in Denali
Note: rereading, I see you're already setting the database on the advanced options for your connection at times. This is no more helpful than that, of course, just prevents you from having to do it each time.
I'm trying to set up mirroring between two sql 2008 databases on different servers in my internal network, as a test run before doing the same thing with two live servers in different locations.
When I actually try and switch the mirroring on the target DB (with
ALTER DATABASE testdb SET PARTNER = N'TCP://myNetworkAddress:5022') I'm getting an error telling me that the server network address can not be reached or does not exist. A little research suggests this is a fairly unhelpful message that pops up due to a number of possible causes, some of which are not directly related to the server existing or otherwise.
So far I've checked and tried the following to solve this problem:
On the target server, I've verified that in SQL Configuration Manager that "Protocols for SQLEXPRESS" (my local installation is labelled SQLEXPRESS for some reason, even though querying SERVERPROPERTY('Edition') reveals that it's 64-bit Enterprise), and Client Protocols for SQL Native Client 10 all have TCP/IP enabled
I'm using a utility program called CurrPorts to verify that there is a TCP/IP port with the same number specified by the mirroring setup (5022) is open and listening on my machine. Netstat verifies that both machines are listening on this port.
I've run SELECT type_desc, port FROM sys.tcp_endpoints; and
SELECT state_desc, role FROM sys.database_mirroring_endpoints to ensure that everything is set up as it should be. The only thing that confused me was the "role" returns 1 .. not entirely sure what that means.
I've tried to prepare the DB correctly. I've taken backups of the database and the log file from the master DB and restored them on the target database with NORESTORE. I've tried turning mirroring on both while leaving them in the NORESTORE state and running an empty RESTORE ... neither seems to make much difference. Just as a test I also tried to mirror an inactive, nearly empty database that I created but that didn't work either.
I've verified that neither server is behind a firewall (they're both on the same network, although on different machines)
I've no idea where to turn next. I've seen these two troubleshooting help pages:
http://msdn.microsoft.com/en-us/library/ms189127.aspx
http://msdn.microsoft.com/en-us/library/aa337361.aspx
And as far as I can tell I've run through all the points to no avail.
One other thing I'm unsure of is the service accounts box in the wizard. For both databases I've been putting in our high-level access account name which should have full admin permissions on the database - I assumed this was the right thing to do.
I'm not sure where to turn next to try and troubleshoot this problem. Suggestions gratefully received.
Cheers,
Matt
I think that SQL Express can only act as a witness server with this SQL feature, you might get better mileage on ServerFault though.
Mike.
Your network settings might be OK. We got quite non-informative error messages in MS SQL - the problem might be an authorization issue and the server still will be saying "network address can not be reached".
By the way, how the authentication is performed? A MSSQL service (on server1) itself must be runned as a valid db user (on server2, and vice versa) in order to make the mirroring work.
We have some scripts that we run as part of our unit tests.
This worked fine until today.
We have tried running scripts with both windows and sql authentication.
We have no problems logging in using sql manager
Anybody have any ideas why we get the following error:
Shared Memory Provider: No process is on the other end of the pipe.
Sqlcmd: Error: Microsoft SQL Native Client : Communication link failure.
Thanks
Shiraz
EDIT
Thanks for the replys. The actual appears to be a password problem, which used up all the connections. The process was not listening because there were no available connections.
Look in SQL Server Configuration Manager and make sure the protocols you are using to connect to it are setup correctly. I suggest you enable "Shared Memory" and "TCP/IP".
Ask around, try and determine what was changed on your environment--by who, and how--that caused a working process to stop working. If succesful, you will (a) have a strong lead on discovering the details of what's going wrong, and (b) be in a position to ensure it doesn't recur. (Just solving the tech side might not prevent it from happening again...)
I have a connection to a Microsoft SQL Server and want the change the connection authenticated user. Is it possible to do it without closing and reopening the connection?
The ideal is something like Oracle set role feature.
I'd love if the solution also works for SQL Server 2000.
You might want to take a look at app roles (sp_setapprole), but you must be aware of consequences being that once the context is changed (e.g. the role is set), it can't be reverted with SQL Server 2000 (it's possible with 2005). The result of this is that the connection is effectively useless when closed in your code, e.g. it can't be returned to the pool and reused, which leads to scalability issues.
Otherwise it is not possible to change the security context once it has been established.
As far as I know SQL Server is very distinct on the account that is passed is the authenticated context. Take Enterprise Manager and other tools for example you must disconnect and re-connect to change users.
Plus looking at the way connection pooling works, it indicates that the connection itself is cached user specific, so if you changed executing parties part way through it would cause major problems with security.
So the short answer, no, it isn't possible as far as I know.
Depending on what you are doing, EXECUTE AS may help you out here. This allows you to execute SQL in the context of another user in a similar fashion to the RUN AS available from the Windows shell. The profiler and audit tracing in SQL Server allows you to see both the original user and which context a statement is run under.
EXECUTE AS USER = 'newuser';
SELECT ... <-- SQL code from under the context of newuser
REVERT;
Note: This is not available under SQL Server 2000 and was added because of requests like yours.