For the five hundredth time, I ran a sql script in management studio to add some tables to a database and FORGOT TO CHANGE THE DATABASE IT RUNS AGAINST. Since it defaults to master, I had to go and drop all the new tables I just added.
I practically never run sql scripts against the master database or other system databases, yet in Management Studio not only are they available in the combo box as a viable target for my scripts, but master is the default option.
Is there any way to remove system databases from this dropdown? Or, at least, change the default database from master???
The default database for your login to SQL Server is set to master. Change it to the database that you use most frequently.
Related
I have created a database in SQL Server 2012 with mdf and ldf pointing to a external hard drive attached to my machine. I created tables, stored procedures, populated tables, etc. etc.
I removed the hard drive at the end of the day.
Today, when I attached the hard drive and tried to access the DB in Management Studio, I see the name of the database with (Recovery Pending).
What does this mean? I see the mdf and ldf files in the D drive.
What worked for me was to take the database offline*, then back online - no RESTORE DATABASE was necessary in this case, so far as I can tell.
In SQL Server Management Studio:
right-click on the database
select Tasks / Take Offline ... breathe deeply, cross fingers...
right-click on the database again
select Tasks / Take Online
When you removed the drive, you forcefully disconnected the database from the SQL Server service. SQL Server does not like that.
SQL Server is designed by default so that any database created is automatically kept open until either the computer shuts down, or the SQL Server service is stopped. Prior to removing the drive, you should have "Detached" the database, or stopped the SQL Server service.
You "may" be able to get the database running by executing the following command in a query window: RESTORE DATABASE [xxx] WITH RECOVERY;
You could, although I would not normally recommend this, alter the database to automatically close after there are no active connections.
To accomplish this, you would execute the following query:
ALTER DATABASE [xxx] SET AUTO_CLOSE ON WITH NO_WAIT;
Another way that works is to "Restart" the Database Engine. If feasible and/or practical for this server, it may be faster whenever you have several DB in the external drive.
In SQL Server Management Studio:
Attach the external drive
right-click on the database engine : Server Name(SQL Server
12.0.2000 ... etc)
Select "Restart"
Answer Yes when asked if you want to proceed
Below worked for me:
Run SQL Management Studio as Administrator (right click on SQL
Management Studio icon and select 'Run As')
Take database offline
Detach the database using DROP option
Attach the database
If you were using this database with a Web App running on IIS then you may need to restart the IIS Server
Hope this helps someone
If the SQL Server knows that database recovery needs to be run but something is preventing it from starting, the Server marks the db in ‘Recovery Pending’ state. This is different from the SUSPECT state because it cannot be said that recovery is going to fail – it just hasn’t started yet.
Check this thread: How to fix Recovery Pending State in SQL Server Database?
If the compatibility level in an Sql Server 2008 R2 database is changed to 2005, can the copy database wizard copy the database without any issues from 2008 R2 to 2005?
Or is Generating scripts the only way to copy a 2008 R2 database to a 2005 database.
I don't believe you can use the Copy Wizard to downgrade your database back to 2005. However, the DataImport... task in SSMS should be able to help you move your data tables and views. (Basically it creates an SSIS package to transfer table definitions and data)
But if you want to truly move the database scripting is your best bet. Also you can check out tools from Red Gate such as SQLCompare and SQLDataCompare.
Just becasue a compatibility level is set to a lower value than the current version does not forbid you to use the newer features. All it does is stop enforcing the removal of features to preserve backward compatibilty of existing code. Since you can use new datatypes and features in your 2008 database, you cannot directly copy back to 2005 without analysis of what new features were used.
If you are developing in 2008 and prod is 2005, you need to stop that practice immediately. Otherwise you will waste a lot of time using new features without realizing it until you try to send to prod.
Database changes should only ever be done through scripts in general as you do not want to risk dropping and recreating tables that have existing data. Also database change scripts should be in source control for the version you are deploying like any other code. Part of making the changes in scripts is that the script you then run on prod has been tested on dev and QA.
Last night I got completely hosed by a worm from Dilbert.com (so be careful there). It is invasive enough where I am going to do a complete system restore. The only thing I need to save on the pc is a database (consisting of just tables & stored procs) in SQL 2008. How can I export them so that, once I restore, I can easily import them again. I thought about doing Access, but that is never completely clean (data types get changed and such).
You should just be able to back up the database from within SQL Server Management Studio. Right-click on the database in the Object Explorer and use the context menu to begin a backup operation.
In addition to the backup operation, which restores everything, you can also use the Generate Scripts option in SQL Server Management Studio to create a text dump of all the tables, keys, stored procedures, users, and so on. This option is available by selecting your database (left click once), right click to get the option menu, then choose "Tasks" (which opens a new submenu) and then "Generate Scripts...". Note that the Generate Scripts wizard is NOT the came as the "Script Database As" option. The "Script Database As" option is very limited, and won't give you many of the database entities you need for a complete restore of the schema.
Alternatively since you are going to take the machine down anyway, just detach the database. Then you can copy the file to an external hard drive or another machine.
I have a SQL Server 2008 DB. I want to extract SOME tables (and associated schema, constraints, indexes, etc) and create a SQL Server Express DB. It isn't a sync of the target, we stomp on it.
We ONLY need to do this in the file system (not across the wire). We are not fond of the synchronization stuff and at this point don't know how to run SSIS. We are a C# shop and a little code is ok. Like using the C# bulk import stuff, but that won't create the schema.
Suggestions?
My suggestion:
Back up the database
Restore under new name and file
Detach restored database from SQL Server
You now have a standalone file that you could use with SQL Server Express.
We use a tool from Red-Gate called SQL Compare to generate schema-complete SQL scripts. It's about $400, but well worth it. You pick the objects you want (users, tables, views, functions - whatever) you want, and it will generate a SQL Script to re-create them in your new database. Essentially, it's the same as Right-Click -> "Script To... New Window" in SSMS, but all at once, and it has a number of other features your shop might find useful as well.
As Scott pointed out (I couldn't figure out how to comment on his post), you can do a backup and restore, detach and attach from one server version to another assuming that the database is less than 4GB.
I have been developing in VB.NET and SQL Server 2008 for a while now, but haven't got into live installs yet. In the database system I used be on it had the ability to archive multiple tables into a .dga file, as it was called. I could then restore the .dga file into another database or on another server.
I'm looking for the easiest way to accomplish something similar in SQL Server.
If you want to transfer specific tables, then using Data Transformation Services (right click on the database in SQL Server Management studio and select "Import Data" and it will bring the dialog up for it). Of course, this assumes that you have both databases available to you.
If you are comfortable with replacing the database as a whole, you can easily backup the database and then restore it into a new one through SQL Server Management studio (or through calling the appropriate SP).
I would go for one of the following :
From MS SQL Management Studio, right click on the database / Tasks / Generate scripts
From Visual Studio, in the Server Explorer tab, "publish to provider"
Both will launch a wizard allowing you to export the tables you want the way you want (including data or not, creation scripts or not, etc etc.)
If you want to move tabless without data, the simpliest thing is to script the tables you want and run the script.
We script all our db changes and commit them to subversion and then run them as part of the deplyment process.
If you want to put the whole database on prod including data (scrub out test records first!), then do a backup and restore onthe other server.
For future changes, wescript all our db changes and commit them to subversion and then run them as part of the deployment process. There also are tools that look at the structural differnces bewteen the two servers and creates scripts. REd-Gate's SQL Compare is really good for this.
In addition to HLGEM's suggestions, you can look into SSIS if this is an ongoing process.