Duplicate Schema in Sql Server 2008 - sql

I am wanting to duplicate an existing schema with the table structure, but not any of the existing data. Essentially, we are separating two companies that currently share a single schema in the database, and they have the exact same data structure, but we want them in different schemas (for access control purposes).
It is possible to copy the entire table structure of one schema into a new schema without bringing over any of the data?

You can do that in SSMS (Sql Server Management Studio)
Right-click on the database
Script Database as
Create to
File
Do a global search-and-replace in the resulting file, changing your schema name to their desired schema name.
I suggest going forward that you maintain change scripts to apply any needed changes to the DB as the application is further developed. That way, you can just share the change scripts and each apply them when you are ready to upgrade the app version.

Related

Use a script to export database Schema and Data into SQL file

I am looking for a means to programmatically pass in a Database name and have it return the Schema and Data as a SQL file. We work with several clients who have complex database configurations and we would like to be able to back up those configurations for our records. The people doing the backups would not know how to use a tool such as SQL Server Manager, as well the chance of producing erroneous SQL files is higher.

New database in SQL Server is getting created with tables from another database on the same server

I have SQL Server installed on my machine with a few databases in it. Now I am creating a new database on the same server: Databases -> right click -> New database.
When I open the database it is getting created with tables from another database on the same server! Did any one see this behavior/problem before? Any possible solution?
It is completely normal. New databases are based on system model database which is template for them.
Model database
When a CREATE DATABASE statement is issued, the first part of the database is created by copying in the contents of the model database
Is used as the template for all databases created on the instance of SQL Server. Modifications made to the model database, such as database size, collation, recovery model, and other database options, are applied to any databases created afterward.
Read also about other system databases and their usage model/msdb/tempdb/model/resource
New databases are created as a copy of the model system database.
By default, this database is empty, but there is nothing stopping a user with the proper permissions from adding tables or data to the that database. Indeed, if you want to control how new databases are created such as default compatibility levels, default languages, default function, data types, etc. then you can do so by creating them in the model database.

Copy datarow from relational database along with its relational data

Using SQL Server 2005\2008
Is there a way to copy a particular data row from one relation database to another similar database, along with its relational data? In a sense that all the other data (FKs) from this database which will need to be there for this particular data row to exist in destination database should also be copied.
I basically need to copy a particular scenario from the production box to test box, without copying the entire table \databases over to test systems.
I can definitely find all the Fk from this table and copy the data manually but that is too time consuming when the base tables keeps changing.
Any tool\ generic queries that can help me move a data scenario from one relational database to other.
I would use SSIS (SQL Server Integration Services) to transfer data from one database to another. It's scriptable and can be automated and scheduled if necessary.
here is my attempt to solve this problem and open source it.
Data Transfer Application

Scripts for moving schema changes from development database to production database

I'm trying to head this one off at the pass. I've got two database servers (DEV and PRD) and I have my database on the DEV server. I am looking to deploy v1 of my application to PRD server.
The question is this: Say in two months, I am ready to ship v1.1 of my application, which introduces two new VIEWS, six new fields (three fields in two tables, each), and an updated version of my sproc that creates records in the tables with new fields. My DEV database has the new schema, but my PRD database has the real data, so I can't simply copy the .mdf file, since I want to keep my PRD data, but include my new schema.
I understand doing the initial creation of tables, views, sprocs via saved .sql files; but what I'm wondering is, is it possible to use SSMS to create the appripriate "alter table" scripts or do I need to manually do this?
I have handled this with a release update SQL script that applies the changes to the previous version.
You either need to code this yourself or use one of the many DBA tools to do database compares and generate a diff script.
There are tools that will do this for you SQL Compare is one of them and one I like the best
Otherwise you have to code these yourself and don't forget to also script the permissions if you recreate the proc (unless you use ALTER PROC in that case permissions are preserved)
Since your database changes should be in scripts that are under source control, you just load them with the version that you are moving to prod just like any other code associated with that version. One you you never under any circumstances do is make changes to the dev (or any other) datbase, using the User interface.
Try the patching engine found in DBSourceTools.
http://dbsourcetools.codeplex.com
DBSourceTools is a utility to help developers get their databases under source control.
Simply point it at a Source Database, and it will script all database objects, incuding data to disk.
Once you have a Target database (v1), you can then place your patch scripts int the patches directory, and DBSourceTools will run these patches in order after re-creating your database.
This is a very effective means of thoroughly testing your change scripts.

Keeping database structure compatible between MS-Access and SQL Server

I'm working on a legacy project, written for the most part in Delphi 5 before it was upgraded to Delphi 2007. A lot has changed after this upgrade, except the database that's underneath. It still uses MS-Access for data storage.
Now we want to support SQL Server as an alternate database. Still just for single-user situations, although multi-user support will be a feature for the future. And although there won't be many migration problems (see below) when it needs to use a different database, keeping two database structures synchronized is a bit of a problem.
If I would create an SQL script to generate the SQL Server database then I would need a second script to keep the Access database up-to-date too. They don't speak the same dialect. (At least, not for our purposes.) So I need a way to maintain the database structure in a simple way, making sure it can generate both a valid SQL Server database as an Access database. I could write my own tool where I store the database structure inside an XML file, which combined with some smart code and ADOX would generate both database types.
But isn't there already a good tool that can do this?
Note: the application also uses ADO and all queries are just simple select statements. Although it has 50+ tables, there's one root "Document" table and the user selects one of the "documents" in this table. It then collects all records from all tables that are related to this document record and stores them in an in-memory structure. When the user saves the data, it just writes the document record and all changed data back to the database again. Basically, this read/write mechanism of documents is the only database interaction in the whole application. So using a different database is not a big problem.
We will drop the MS-Access database in the future but for now we have 4000 customers using this application. We first need to make sure the whole thing works with SQL Server and we need to continue to maintain the current code. As a result, we will have to support both databases for at least a year.
Take a look at the DB Explorer, there is a trial download too.
OR
Use migration wizard from MS Access to SQL Server
After development in Access (schema changes), use the wizard again.
Use a tool to compare SQL Server schemata.