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.
Related
I am using microsoft sql management studios to maintain a really large database. I want to make a backup version so that our developers can view data from the backup. I saw that there is a "Copy Database" option and an "Export Database" option in microsoft management studios. What are the differences between these?
The reason I ask is our database has a lot of important data and we want to have a way to view previous data (not just create a backup to restore the db)
According to Microsoft documentation, copy database allows you to do the following :
Pick a source and destination server.
Select databases to move, copy or upgrade.
Specify the file location for the databases.
Create logins on the destination server.
Copy additional supporting objects, jobs, user-defined stored procedures, and error messages.
Schedule when to move or copy the databases.
In my own word, I would say that copy database allows you to easily move a database from an instance of SQL server to another one.
Export database save the database to a file in the OS file system (like a backup). You then can copy those files and import them whenever and wherever you want.
I work in a small company which is running M/S SQL Server 2005
Now our head office is asking me to give the whole database backup with the table schema in a single file of *.sql
please help me to backup my database in a *.sql including the table schema.
Thanks in advance.
Use SQL Server Management Studio
right click on your database and choose Generate scripts... and hit Next
choose Script entire database and all database objects and hit Next
choose Save to file and enter a path and a file name for your future sql script file. On the same screen choose Advanced and change the Types of data to script property value from Schema only to Schema and data. Hit OK. Hit Next.
and hit Next again.
You can download, install, and use SQL Server Management Studio that comes free with Microsoft® SQL Server® 2012 Express for that
I would go out and download Microsoft SQL Server Management Studio Express.
http://www.microsoft.com/en-us/download/details.aspx?id=8961
It is free. You will be able to connect to the database, drill down into Databases, right click and under Tasks, pick Backup Database. Make sure you pick full...CHoose Disk as the place you want to write it to and Execute...Look thru your options as well...
Hope this helps!
I’d go with the method peterm suggested but note that this also has flaws. Problem is that SSMS doesn’t order the scripts in correct execution order.
For example, it might happen that DDL for stored procedure P is before DDL for table T that is used in P.
All you need to do is to review your script and make sure there are no such cases. If there are you can try fixing this yourself or using some third party tool to generate script that is ordered correctly.
What is the best way to go about moving a database from a Godaddy SQL 2005 account to a local SQL 2005 server? I have access to the DB through Server Management Studio Express and also through the Godaddy SQL explorer.
However, I have no idea where to start. In MySQL, I would just export the data through the PHPMyAdmin page, and conversely import it on the other server using an ASCII file. In access, I'd just use the migrate tool. In Server Management Studio, I've thought about using the "Backup" and "Restore" method, but I'm afraid that I won't have the ability to create a new object with the correct permission schema on the new server.
What are your thoughts? Keep in mind that I do not have access to the MDF or temp files. I've been studying this page.
SMSS should be able to do it for you. If you are looking to move the entire database and not just a few tables, the Backup and Restore method is probably your best bet.
Your steps might include:
connect to Godaddy sql server in ssms
Right click the database you want to move and select Tasks > Backup
Keep/set Backup type = "Full" and add a destination at the bottom that you will be able to access.
After backup completes, move the .bak file to a location that your local sql server can see.
Connect to your local sql server in ssms.
Right click Databases > Restore Database
Enter the database name you want in "To Database:"
Select "From device:" and locate the .bak file you created before.
In the row that shows up in the grid display, check the restore check box.
If it matters to you where the recreated files will be stored, select options on the top left menu and confirm the file locations under the "Restore As" column in the data grid.
Click ok and the restore should start.
To migrate users, follow the directions at http://support.microsoft.com/kb/918992
Don't be so afraid of the backup and restore. You have a much better chance at getting a high fidelity copy of your data than trying to roll your own. Give it a shot, test it out, and see what happens. I think you'll be pleasantly surprised.
iv created a database with some tables and populated them using SQL server 2008, i want to move the database to another machine, what would be the best way copy the database and recreate it in another location ??
by the way im connecting to localhost\SQLEXPRESS if thats important !!
thanks
Backup and restore is usually the simplest way. The only complexity you may encounter is that your may have to recreate and associate users on your target system.
Do a backup of your database and then restore it on another machine
Right click on your database in SSMS. Choose Tasks->Backup. Then choose your location and click ok. Take the backup file you create out of the folder it was in and put it into the same folder on your other computer. Then open SSMS on your other machine. Right click on the database folder and click Restore Database. Enter what you ant to name it, choose From Device and then find your file. Click OK and you are done.
I would use SQL Server backup and restore. I believe you can backup in SQLExpress (you just can't schedule one).
Right click your database, and select Tasks -> Backup. Do the backup.
On your other sql server instance create a database with the same name. And do Tasks -> restore -> database
If you have permissions to restore on the target database server then that is by far the best way to copy the database.
If you don't have permissions, then you'll want to connect to the source and target databases with Management Studio and Import the data from the source. If you have simple primary key only indices on your tables you can import by right clicking on the target database name, then select Tasks, then Import Data. A wizard will walk you through it.
You can practice by importing the data into a new database on your local machine first.
If you have more complex indices or functions, sprocs, and views, you'll want to create the new database first, before you import the data. Same procedure, but select Generate Scripts. The wizard will walk you through the necessary steps. Under script options you'll want to make sure you select True for Script Indexes.
Again you can practice by recreating and importing locally. Though if you create locally you'll need to give the database a new name.
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.