I have databases with different collations. I want to be able to script out tables from one database and create them in another. However, when I script out the tables, it includes the collation in the column definitions.
Is there a way to exclude the collations from the generated table creation scripts?
Tools -> Options
Under Scripting (in the Table/View section)
Set Include Collation to False!
Pretty lame - but do a search and replace on the script after it has been generated??
Which version of SSMS are you using? The full edition, or Express edition?
You'll need to apply at least SP2 for 2005 to get the scripting settongs under Tools->Options.
This doesn't need to be applied to the database servers, it can be applied to just the client tools on your admin workstation if required.
Related
Dear all, Currently I am just researching how I could handle the change of the collation on the database.
Somebody made an unusual decision to create accent sensitive database for global use... but I am on the way to handle this!
REASON: of changing the collation is that database contains data collected from different countries and as we all know some of cultures have their own letters.
With the respect for the customers, our organization would like to have Accent Insensitive database. That will allow users to request data from the server without any limitations using local characters.
As far as I have find out, there may be an option to drop constraints and etc. change collation and then just to bring everything back. In this case I am afraid if this would be enough to affect already existing data (columns).
Another way, I have found an article in Collation change on 2005 and 2008 server. However, this does not include the 2012 server.
Also I am taking the complexity of this example into consideration as well.
I believe that I am not in an easy phase. But I am hoping to get few advises what would be the best and safest way to handle this.
Thank you for your concerns and assistance.
UPDATE let me add what architecture do we have: The complete system contains 4 databases and more than 1.000 tables in total. So my expectations is that not all of the possible ways may work in an optimal way.
me too i had to deal with a similar issue because of a different reason: ancient databases with an old SQL collation installed ages ago on a SQL6.5 server that has been inplace upgraded for each version from sql 7 to sql 2005 and now should be updated to sql 2012.
why all these inplace upgrades? because the actual collation was the server collation and was so old that is not available during then install process of a recent version (2000+) of sql server...
i decided to drop all that old rubbish so i had to find a way that allowed me to move to a new installation with a windows collation.
i had to exclude the data migration (create a new database and import data) because of the lack of documentation and the huge number of customizations, triggers, hidden rules and so on.
the solution i used (the order matters):
disable automatic statistics generation
script the creation of all foreign keys and then drop them
script unique and primary indexes and then drop them
script all remaining indexes and then drop them
script custom statistics and then drop them
script CHECK and DEFAULT constraints and then drop them
now you can run the ALTER commands needed to change the collation of the columns and change the collation of the database itself.
when done repeat the above in reverse order to rebuild all the needed objects.
it happens that if the database is so old as is mine you may incur in something funny like existing foreign key that references fields with different datatypes.
Changing collation of all existing columns is a real pain. I suggest a side-by-side migration rather than alter each column individually. Create a new database with the desired collation containing only empty tables. Copy data from the old db to the new one using INSERT...SELECT (or the ETL tool of your choice), and then create constraints, indexes, and other database objects.
Consider upvoting the Make it easy to change collation on a database SQL Server feature request.
There are a number of complicated solutions on the internet for inplace collation changes but the simplest (and safest) way we have found is to script out the database, alter the script to create a new db with the collation set at the start and then import the data to the new database.
We achieve this using MS SQL Server 2012 Management Studio in the following way:
Script out all database objects with Tasks -> Generate Scripts -> Script entire Database and all Database objects
Alter the script with the following 2 changes and then run it to create a new database:
a) Change DB name to MY-NEW-DB
b) Under the CREATE DATABASE statement add: ALTER DATABASE [MY-NEW-DB] collate Latin1_General_CS_AS
If desired, use a tool like RG SQL Compare to compare the old and new database to verify all indexes, constraints, types etc were the same and collation on relevant columns only was changed.
Run Tasks->Import Data ensuring 'Enable Identity Insert' checked. All data transferred to the new case sensitive database correctly.
Run DBCC CHECKDB if you wish to check consistency
I'm assuming this is not possible but asking just in case. I have two database projects in my Visual Studio 2013 solution and Database Y mostly just has shortcuts to tables in Database X. Everything worked great until I added partitioning to the definition of Table A in Database X. Since I deploy Database X to SQL Server 2012 Enterprise and deploy Database Y to SQL Server 2012 Standard, and partitioning is not allowed in Standard, the latter deployment fails.
Is there a way to tell the database project for Database Y to ignore the partitioning stuff? Any other ideas on how to keep the tables in sync without using a shortcut?
UPDATE: Here is the error.
Creating [PartitionByReportFileID]... (75,1): SQL72014: .Net SqlClient
Data Provider: Msg 7736, Level 16, State 1, Line 2 Partition function
can only be created in Enterprise edition of SQL Server. Only
Enterprise edition of SQL Server supports partitioning. (74,0):
SQL72045: Script execution error. The executed script: CREATE
PARTITION FUNCTION PartitionByReportFileID
AS RANGE RIGHT
FOR VALUES (90000000, 120000000, 140000000, 160000000, 180000000, 200000000, 220000000, 240000000, 260000000, 280000000, 300000000,
320000000, 340000000, 360000000, 380000000, 400000000, 420000000,
440000000, 460000000, 480000000, 500000000, 520000000, 540000000,
560000000, 580000000, 600000000);
An error occurred while the batch was being executed.
UPD: Well, it's possible, though you probably won't like the approach.
Indeed, SSDT includes partition-related stuff into the deployment script no matter how hard one tries not to allow it. The other way is to create an empty database and then perform a schema compare between the project (source) and that database (target). In the schema compare settings, make sure 2 checks are set on the General tab:
Ignore object placement on partition schemes
Ignore partition schemes
This works in SSDT 2012, verified. From this point on, you can either run an update directly, or generate script and then use it for deployment, with only minor modifications (such as adding the database (re)creation part from the standard deployment script, if needed).
The only drawback with this approach is that previously partitioned tables appear on default filegroup, which is usually PRIMARY unless you change it. That, and post-deployment script functionality isn't included, afaik (assuming you have one, of course).
My primary reason for this is to keep track of database schema changes for my application. In SQL Server Management Studio I am able to generate a create script which creates the database but it doesn't contain any test data. Ideally when the script is run it should DROP the existing database (assuming it already exists) and then recreating it using this new script containing schema changes and test data from my development machine.
So how can I generate a script that will create a database with all the tables, stored procs, triggers, views, test data, etc?
I've tried using the import/export functionality but that's no good because it doesn't seem to copy over stored procedures. Plus it would be nice to have a script so I can track changes to the schema using mercurial.
I am using SQL Server Express 2008 R2 along with SQL Server Management Studio.
You didn't mention which version of SQL Server, but in SQL 2008 this is very easy
SQL 2008
Expand Databases
Right Click Database
Choose Tasks > Generate Scripts
Generate and
Publish Dialog will open Choose your
objects (i.e. Tables, procs, etc)
Click Next On the Set Scripting
Options choose Advanced Options Under
General choose SCRIPT DROP AND
CREATE - SCRIPT DROP AND CREATE
Types of Data To Script - Schema and
Data Close Advanced Window Choose to
save to file.
I wrote an open source command line utility named SchemaZen that does this. It's much faster than scripting from management studio and it's output is more version control friendly. It supports scripting both schema and data.
To generate scripts run:
schemazen.exe script --server localhost --database db --scriptDir c:\somedir
Then to recreate the database from scripts run:
schemazen.exe create --server localhost --database db --scriptDir c:\somedir
Try Microsoft SQL Server Database Publishing Wizard. This is a powerful flexible tool for scripting schema / data rom SQL Server.
Personally I use Microsoft Visual Studio 2010 Database Project with a Source Control Repository (SVN) to track changes to the schema.
Watch out for difference in database collation. If you develop on a database with a case insensitive collation and try and run the SSMS generated scripts against as database with a case sensitive collation then errors in case will break the scripts.
Usually i make backups fom a database before start a new development on it.
the best way is restore the backup when needed, i don't know how to get it by the script way!
I'm looking for command line or scripted solutions to pull the DDL out of SQL Server 2005+ for all database objects: tables, stored procs, views, indices/indexes, constraints, etc. GUI tools are not of interest.
Preference is for built-in tools, since that would be the most comparable to Oracle's DBMS_METADATA stuff. Also, preference for a solution that is as simple as Oracle's for getting the DDL out - eg, a one liner:
SELECT DBMS_METADATA.GET_DDL('TABLE', 'MY_TABLE') FROM DUAL
Note: Getting things out for procedures in SQL Server 2005 seems easy, but I can't find any references to something similar for other objects (like tables).
SELECT definition
FROM Sys.sql_modules
WHERE object_id = OBJECT_ID('MyProc')
Thanks in advance!
There is no support in the Transact-SQL language. The client libraries (SMO) can do it using a Scripter object, see example at http://msdn.microsoft.com/en-us/library/ms162153.aspx. You can use SMO from PowerShell as a scripted solution.
The SQL Management Studio also has an option (right click on a database, go to Tasks, select Generate Scripts), it uses an SMO Scripter under the covers.
I wrote SMOscript, a command-line tool which uses SMO to generate DDL files of all database objects.
I'm trying to replicate a rather large database from SQLServer 2000 to SQLServer 2008, located on two different servers. I found an article about attempting this and have been trying to follow its direction. Here is the article.
Mixed Mode Bi-Directional Transactional Replication between SQL 2000 and SQL 2008
Here is the part I'm stuck on:
"So, to create a publication, you will
need to NOT use the publication wizard
that you get in SQL 2008. Instead, use
a generated publication script and for
each sp_addarticle line that you have
in it, make sure that the #ins_cmd,
#upd_cmd & #del_cmd parameters point
to the appropriate stored procedures
and run it on the SQL Server 2000
server. Once this is done, go ahead
and create a subscription to SQL
Server 2008’s database normally."
I was able to get the stored procedures in place for all of the tables but need some direction on creating a generated publication script. Does anyone have some direction or a good example of a generated publication script?
On the final step of the publication wizard you will have the two options:
1. Create the publication
2. Generate a script file with steps to create the publication
The article referenced here is suggesting that you do not let the wizard create the publication but instead only choose to generate the script file. At that point you can edit the script file as instructed in the article.
You can run through the SQL Publication Wizard in 2008 and have it output to a script and then use that as a base model to modify with the appropriate arguments for the sp parameters listed in the question.
I'm just doing an upgrade of SQL 2000 to SQL 2008 R2 and I'm finding the publication wizard works just fine without any need to modify the scripts generated.
The article suggests creating some stored procs because it does not work bi-directionally out of the box. However, when it works brilliantly both directions, and very quickly too, just using the wizard. This is using SQL 2008 R2 which may be the reason, it may have improved since the original SQL 2008.