I'm looking for a way to duplicate an existing database, tables and data onto a different development machine. Using SQL server 2008;
I have several tools i usually use for duplicating databases or i just restore a database dump, but i cannot use any of these. I have no direct access to the database machine i can logon via SQL enterprise manager and run queries stored procedures etc. But i have no access to the file system so i'm unable to create or copy a database dump. I cannot install or connect any tools to the database as i have to logon via a remote desktop. I also only have access to copy text files on and off the network.
I would like to run a script to generate a script to create the tables, views stored procedures etc and a script to populate the tables with some data.
I need to create a test environment so i can run tests and develop new features without affecting the live DB.
Assuming you have access to the database via SSMS, this is the approach I would take, though it could be time consuming:
Right click on the Database
Hover 'Tasks'
Hover 'Generate Scripts' and complete the process, it's self explanatory.
And from there it will generate a script for the Database architecture. This is the quick portion.
Next download Visual Studio and get the Integration Services add on. Using SSIS packages you'll be able to select all data from each source table/database and then insert the data into the destination table/database. Hope this helps you get on the right path.
Related
I work for a customer who has his own database management team and I need to deploy my new web application version within a SQL Server 2008 script (I am not in position to execute any actions on their systems). I can't back up myself their database and I'm not sure they'll do it so if I delete all data it's gonna be terrible.
Therefore, I'm looking for a solution to back-up if possible the database, extract the existing datas, execute the new statements of my script, and re-include the datas saved in the database.
It is possible to do this in a SQL server script ?
More generally, how can I safely update schemas and datas of a SQL Server database within a script without losing all data inside ?
PS :
Currently, I'm using in the dev environment the initial database schema and the newest. So, I use Visual Studio 2012 with Data Tools to make Schema comparison and generate the update script.
You start with a copy of the database schema with sample data against which you can develop and test.
Then you write scripts (perhaps with the aid of a tool like SSDT) that updates the schema to be compatible with the new version of your application, retaining the data in the database.
You deliver these tested schema modification scripts along with the new version of your application for the customer's administrators to test and apply to the target database as part of the application upgrade.
I have a rather large database I am working with and I am about ready to break something. To prevent this affecting live data, how would I use the live database to setup a local database? Not sure if this is even possible but I do know you can setup a local db.
You can create a SQL Server Data Tools database project type, then right click the project file and do an "Import..." to import the database to your local machine. Then you can deploy the local DB and it will be available in the SQL Server Object Explorer locally. This way you don't have to install SQL server on your machine - everything's in Visual Studio. Hopefully you are developing with a small set of data locally.
Answer
Use Visual Studio's Data Comparison tool to synchronize data to your target database from your source after you've created the database (schema only, no data) in your local database server.
Steps
From the Visual Studio's SQL Server Object Explorer:
A. Create the local database
Add two SQL Server Objects: One that connects to your production server and one that connects to a local (development/testing) server. If you need help setting up a local server then take a look at SQL Server LocalDB
Add a New database in your local server to receive the data (don't over think this step).
B. Migrate the Schema
Right-click the source (production) database and click Schema Compare...
From the SQlSchemaCompare tab that opens, use the Select Target dropdown to select your local database as the target.
From the SQlSchemaCompare tab, click Compare.
Uncheck everything in the comparison results except for the Tables, Views, and Procedures (unless you know what you're doing) then click Update.
C. Migrate the Data
Right-click the source (production) database and click Data Comparison...
Follow through the prompts to select the Tables to migrate then click Finish.
From the SQlDataCompare tab that opens, review the comparison results (it should make sense to you) then click Update Target
That's it! Either your local database is ready with data, or you confused your target/source and wiped out all of your data in production. Either way, you're done for the day.
Our company is in the process of adapting TFS for source repository and project management. I am in charge of database part of the project. We are using SQL Server 2008 R2, Visual Studio 2012 and TFS Online. We have a database that is used by several of our applications. So far I have been the only one handling any change to this database. As the company is expending we are going to have multiple dev teams. So I am planning to save the database as as SSDT project to TFS.
At the moment I am maintaining my database like the following:
I have separate folders for UDFs, Stored Procedures, and Config.
Under these folders I have subfolders for each objects. For example, for stored procedures I have subfolders for each stored procedure which contains the SQL script to create the SP. The config folder contains any script similar to SSDT's post deployment script (for example, populating static data).
The SQL script contains code to drop the procedure and create it.
I have a c# app to concatenate all the SQL files into one single SQL file. Let's call it the FINAL script. When creating FINAL script I can specify version number which adds an update statement to update the version table on the database.
FINAL script is made available for customers to download and execute on the database. So the script mainly contains any add/edit to SPs, UDFs, and static data. It does not touch any existing data (data entered by user) in most cases.
As a newbie to TFS and SSDT I am not exactly sure how this can be done using SSDT/TFS or if there is better way of doing something similar. So far what I have understood about SSDT and TFS is:
I can import an existing database to SSDT project.
This will create scripts for all objects including tables.
I can easily do a publish of the database to a local server or to a server I have access to.
Things that seem confusing so far:
How do I supply clients with my latest update script? I am thinking of manually including the FINAL script to the SSDT project but there must be better way of doing it.
How do I publish the changes to a copy of the database without the loss of any user-entered data? My guess is when publishing the tables get created. I can take care of the static data but I am not sure how to handle data entered by users.
May be there is something fundamentally wrong in my understanding of this whole thing. That is why I am here... :)
You want to pull your DB into a SQL Project. Maintain all of your changes there. This tells your system what the schema of your database should be. From there, I'd generate the dacpac files (through building the project) and provide those to your clients along with having them install the SSDT tools that include SQLPackage. They can run SQLPackage to make changes to their database to handle the schema changes automatically. This will bring their database in line with your schema, no matter how far off it might be.
I'd also create a publish profile for them to use. This lets you control some of the settings.
You can choose to not drop any objects not in your project
You can choose to ignore users/permissions
You can set an option to not allow changes if there would be data loss.
You can wrap everything in a transaction so a failed update rolls back
If you give them a batch file to run, you can specify an output file or a Diff report, or have them generate their own script to do the update.
I blogged about this at http://schottsql.blogspot.com/2013/10/all-ssdt-articles.html
(or http://schottsql.blogspot.com/search/label/SSDT if that doesn't work well). That will take you through some basics of why you might want to use SQL Projects, creating them, maintaining them, and publishing the changes to an existing database.
I have a database on one server that I need to copy to another server. I can do this manually using the Export Data task, which is fine for a one time export, but I would like to speed this up as it is going to be repeated.
The database will always contain the same set of tables, I just need to get a copy of this database with it's tables and their data from one server to another.
I'd like to create some sort of reusable tool that allows you to specify the source and target database servers and then copies this specific database from one to another. Is this possible?
The Export Data task in SQL 2005 and later uses SQL Server Integration Services (SSIS) under the hood. You can save the package you're already using and run it on a schedule or on demand. You can also edit it (once it is saved) using the Business Intelligence Development Studio (BIDS).
At the end of the Export wizard (on the "Save and Run Package" screen), you can tick the "Save SSIS Package" check-box to store the package either within SQL server or on the file system. The file system is probably simpler.
Once you have the package you can execute it from the command line using the dtexec tool, or from a SQL Agent job using an Execute SSIS task.
SSIS is too big a subject to cover in full here - there are decent tutorials within SQL server books online if you need more details - alternatively, as another SO question if you get stuck.
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.