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.
Related
As soon as I log in to my server instance I get :
Object reference not set to an instance of an object.
(Microsoft.Visual.Studio.Platform.WindowManagment)
I tried repairing Management Studio. No result.
Tried repairing the SQL Server instance. Nothing.
Tried repairing *.Net 4 ... Same thing.
I can not do anything in the Managment studio except run queries.
All of my databases are not shown.
I have an hunch that database mail is malfunctioning but I can not get into
SQL Server agent to correct the issue (Modify the job). Stopping it makes no difference.
I have seen lots of similar issues here but they do not help me in any way.
How can I get in control of my server instance ? I really don't know what else to do. Is there something I can do apart from reinstalling? I am virtually locked out.
This error can be caused by so many things that's impossible to find out.
I have narrowed the culprit to corrupt internet explorer installation.
Why it became corrupt I don't know.Maybe some update. I actually almost never used it.
Bottom line, I had to reinstall the windows server and sql server from scratch. 2 days of work.
Thank you Microsoft.
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.
I wouldn't describe myself as afraid of change - but afraid of new technologies? YES INDEED! Technologies from operating systems, to database servers just seem to become bugged, inefficient and backward the further they "progress"
MSDE 2000 (what they might call "SQL 2000 Express" in today's world)
BACKUP [MyDatabase] TO FILE 'c:\backups\mybackup.backup'
SQL 2008 EXPRESS
Wait up! Its a 'user instance' - to back it up we need to attach it to a server instance
Wait up! To attach it we need SQL Management Studio Express (78MB download)
Wait up! When we login to our .\SQLEXPRESS server instance and try to attach our database it gives us an error that literally looks like a bug in our homebrew dev project:
TITLE: Microsoft SQL Server Management Studio
Cannot show requested dialog.
------------------------------ ADDITIONAL INFORMATION:
Parameter name: nColIndex Actual value
was -1.
(Microsoft.SqlServer.GridControl)
Can someone explain how to backup a user instance of a SQL Server 2008 Express database in T-SQL code?
(sorry if this comes across like a flame at ummmm, Microsoft - I'm actually a huge fan of theirs. Just really angry about things like this! please don't vote me down...)
Um, if it's a user instance, then the simplest backup strategy is to copy the file. (whilst it's not connected to SQL Server).
If you need a more comprehensive backup strategy (e.g. transactional backups), then you really should be looking at a more comprehensive database (e.g. a "normal" one attached to a full SQL Server instance)
SOME KEY TIPS TO NOTE WHEN TRYING TO ACHIEVE USER INSTANCE BACKUP
a.) Connecting
Your connection string should look like this:
Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\MyDatabase.mdf;Integrated Security=True;User Instance=True;Database=MyDatabaseAlias
It is essential that your connection string gives the connection an alias Database=MyDatabaseAlias - this alias cannot be duplicated concurrently on the same machine or your connection may fail.
b.) Backing Up
As pointed out above, the Transact SQL to backup a database is the same on SQL MSDE/2000/2005/2008/R2 - once you have your database attached and aliased!
BACKUP DATABASE MyDatabaseAlias TO DISK = 'c:\backups\mydatabase_20101117.backup'
Whats truly amazing is the bull$h!t errors you can get because your connection string doesnt have the alias Database=MyDatabaseAlias part.
e.g. Unable to open the physical file 'c:\Code\MyProject\App_Data\MyDatabase.mdf' Operating system error 32: "32(The process cannot access the file because it is being used by another process.)".BACKUP DATABASE is terminating abnormally.
c.) Restoring
USE [master]; RESTORE DATABASE MyDatabaseAlias FROM DISK = 'c:\backups\mydatabase_20101117.backup' WITH REPLACE
Do not forget the all essential USE [master]; at the beginning of this statement (and note that its all on one line for those executing the command from a DataContext or similar) If you do, it wont be able to overwrite the existing database because you'll still be connected to it.
Once again, the assortment of totally misleading errors you might receive here, due to an invalid connection string, is endless.
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. :-)
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.