I state that I'm new to SQL Server.
With my company we are planning to migrate from SQL Server 2008 to SQL Server 2012 and I have this question.
The application which uses SQL Server 2008 was born as a one language application (Italian in this case) but later has been converted to a multi language application that requires UTF-8 encoded data.
So the DB server has been filled with custom "collation" clause on column, query and procedures to avoid data encoding errors.
Now we have configured a SQL Server 2012 instance with all the right collation since the start and I was wondering in how to migrate data between servers.
How can I tell the dbms to dump the data into UFT-8 and omit all those "collation" clauses?
Sorry for my bad English.
Related
I would like to use Always Encrypted as part of SQL 2017 or SQL 2019 to encrypt a few columns but those columns are currently involved in transactional replication in the architecture. Always Encrypted does not appear to support transactional replication in SQL 2017 (would like to confirm) and I cannot find an authoritative answer for support with SQL 2019.
We successfully tested implementing Always Encrypted in SQL 2017 on columns in a table that are not involved in transactional replication. We could not get Always Encrypted to work for tables for those columns involved in replication. This validates the documentation that it is not supported. Not sure if there are any workarounds. The documentation for SQL 2019 seems to mirror the SQL 2017 documentation but I want to validate the limitation because I don't know if the documentation has been updated for the soon-to-be-released version of SQL Server.
Not code related
I was hoping that a key technology in SQL Server (transactional replication) would have introduced support for Always Encrypted columns over the course of 3 releases.
I'm planning to migrate all the SSRS reports from 2008R2 server to new sql server 2014 environment. As far as migration is concerned, I was asked to take the backup of 2008R2 report server database and restore it in 2014 server.
I was not convinced with this since there may be new tables available in 2014 Report server.
The new features of 2014 cant be utilized if the old report server database is restored.
Please let me know if this thought is correct.
Are there any new tables available in 2014 report server database?
What is the best option to migrate ssrs reports from 2008 r2 to 2014 server?.
Your question is a bit confusing, I will assume you want to move the database from a Server A with SQL Server 2008R2 + SSRS 2008R2 to a Server B with SQL Server 2014 + SSRS 2014.
Are there any new tables available in 2014 report server database?
There is no official communication on it.
If you really want to know it you could do a schema compare between the 2 versions.
But do not forget to compare everything, not only tables:
Columns
Stored Procedures, Functions
...
Database structure is not the only thing to take into account, what about:
All the configuration files
Encryption Keys
...
What is the best option to migrate ssrs reports from 2008 r2 to 2014
server?.
Short answer:
My recommended way of doing it would be to use RS Scripter and generate a script on Server A with all the objects (reports, datasources, subscriptions, ...) you want to move.
Then you can restore it on Server B.
Long answer:
If you really want to migrate the full database like you were asked to do, there is no officially supported way to move the database to another SQL instance and upgrade the version at the same time.
You could try to follow the steps to Backup and Restore Operations for Reporting Services, and apply it to a newer SQL Server instance with another SSRS version, but it will be at your own risk.
The supported ways to do would be to either:
Upgrade from SSRS 2008R2 to SSRS 2014 on Server A
Move from Server A to Server B
or
Move from Server A to Server B
Upgrade from SSRS 2008R2 to SSRS 2014 on Server B
Here are the related MSDN articles for these operations:
Migrate a Reporting Services Installation (Native Mode)
Upgrade to SQL Server 2014
Again, I would advise using a tool to migrate the reports and other items instead of trying to migrate the full database.
I do not think restore 2008R2 reportserver db on 2014 will work, because the report definition schema is totally different.
I did a migration task to move 2008R2 reports to 2012. Because there are hundreds of reports on the 2008R2 server, I found the easiest way is to write some codes to read report definition, and then create on 2012 server.
From: https://msdn.microsoft.com/en-us/library/ms143747.aspx
There are two general approaches to upgrading a Reporting Services
deployment:
Upgrade: You upgrade the Reporting Services components on
the servers and instances where they are currently installed. This is
commonly called an “in place” upgrade. In-place upgrade is not
supported from one mode of Reporting Services server to another. For
example, you cannot upgrade a Native Mode report server to a
SharePoint mode report server. You can migrate your report items from
one mode to another. For more information, see the ‘Native to
SharePoint Migration’ section later in this document.
Migrate: You
install and configure a new SharePoint environment, copy your report
items and resources to the new environment, and configure the new
environment to use existing content. A lower level form of migration
is to copy the Reporting Services databases, configuration files, and
if you are using SharePoint mode, the SharePoint content databases.
If you do an in-place upgrade from SQL Server 2008R2 to SQL Server 2014, then everything should work as expected.
I'm asking for the proper way, in SQL Server's T-SQL (I think that's what it is) code or using another language, to import data from a Microsoft Access MDB Database into a new SQL Server Database.
Now, typically I would just import it in. The problem is I'm writing a .SQL script (I could use another technology if needed) to do all this leg work as this will need to be done fairly regularly. Likely at least once a week, for about 5 months in the year.
To digress a tad, I had wanted to implement a single database and distinguish separate source database using something like a DatabaseID field, but the powers that be overthrew me there.
I was previously using SQL Server Management Studio 2012 with SQL Server 2008 running the T-SQL (on a production machine) that worked fine. I've now migrated to a local SQL Server Management Studio 2012 with SQL Server 2012 (for development) and the code that used to work doesn't anymore.
This code is what used to work: SELECT * INTO [dbo].[Controls] FROM OpenDataSource('Microsoft.Jet.OLEDB.4.0', 'Data Source=C:\Show.mdb; Jet OLEDB:Database Password=BobSaget')...[Control] The password has been obfuscated for security ...
That's likely a sloppy solution. What's the ideal way?
Thanks in advance!
I would recommend using Microsoft's SQL Server Migration Assistant for Access.
SQL Server Migration Assistant (SSMA) is a free supported tool from Microsoft that simplifies database migration process from Access to SQL Server. SSMA for Access automates conversion of Microsoft Access database objects to SQL Server database objects, loads the objects into SQL Server, and then migrates data from Microsoft Access to SQL Server.
SSMA for Access v5.2 is designed to support migration from Microsoft Access 97 and higher to all editions of SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, and SQL Azure.
You can find it here.
You may need to fix the structure after the migration as it tends to over exaggerate many of the data types.
Have you checked your DCOM security on MSDAINITIALIZE?
I had this problem when moving to a local instance of SSMS 2012.
http://blogs.msdn.com/b/dataaccesstechnologies/archive/2011/09/28/troubleshooting-cannot-create-an-instance-of-ole-db-provider.aspx
I've been working on SQL server 2005 for a few years and i'd never come across collation issues. However i installed SQL 2008 on a virtual machine and tried to sync my 2005 database with the new 2008 server using Redgate SQL compare. It failed complaing about the collation on the 2 servers being different.
After a quick bit of research i discovered my 2005 is using Latin1_General_CI_AS and the new 2008 installation is using SQL_Latin1_General_CP1_CI_AS.
Why is 2008 using something different to 2005? Both times i've just done a default install. Secondly what should i do to get them the same, which collation is the correct one?
I do not know what criteria is used for the MS SQL Server installer to select default collation.
Collation of a server does not have to be the same as the collation of a database on that server. Collation of a database does not have to be the same as the collation of table columns in the database.
You can set the collation of the database when you create one. Default it will get the same collation as the server.
Here is a post about how you can change the collation of a database including changing the collation of columns.
Changing SQL Server Database sorting
with a reference to here http://support.microsoft.com/kb/325335.
Here is a starting point if you need to change the default collation of a server
http://msdn.microsoft.com/en-us/library/ms179254.aspx.
I do not know what is necessary for Redgate SQL Compare, but I guess it only needs the database collation to be the same. So if you are replicating a db to a new server you probably only need to create the new db with the same collation as the one you already have and leave the default collation of the server as is.
Is it recommended to use two versions of SQL Server (2005 and 2008) for storing data of an application. We have a situation where we have an existing web application consuming SQL server 2005 as a database. Some enhancements in the application required us to solution a FILESTREAM data store. Now we have our data in SQL Server 2005 and associated FILESTREAM data in SQL Server 2008. Being very new to SQL Server I would like to ascertain how bad is this in terms of performance? How can we achieve atomicity across both the database versions, is it via using a linked server or some other mechanism? Any alternative solutions would be fine except that we just cannot migrate the existing application to SQL Server 2008.
To keep your transactions ACID, you can use distributed transactions at a stored procedure level, or from a code level using DTC (e.g. via a .net TransactionScope). DTC would need to be present on both SQL Servers, and on your App Server as well if you do the ACID from there. There is some overhead with DTC
Edit : You will also need to link the servers with sp_addlinkedserver and provide credentials with sp_addlinkedsrvlogin