I am using Data Migration Assistant to assess compatibility issues migrating a SQL database to Azure SQL. After running for a couple of minutes, it throws an error saying "The file contains the XML node type {0}. This type is unsupported or in an unsupported location." I have successfully assessed other databases using DMA but this particular database always aborts after throwing this error.
I decided to go ahead and migrate the database using the wizard (Deploy Database to Microsoft Azure SQL Database) from SSMS, and ran into several compatibility issues that showed as errors. The database had several triggers that were created by a third-party database tool that referred to table objects with the 3 & 4-part naming conventions which is not supported on Azure SQL. There were several other errors in addition to these but I decided to delete these triggers first and run Data Migration Assistant again. This time it ran to completion and I got compatibility report. I am not sure if it was the sheer number of issues found or something in those triggers that I deleted had caused the error.
Related
I have an on premise SQL Server database that is the backend for our project management software, a Azure sql table that contains limited data used for reporting with power bi and a linked server to connect the two. Both of the databases have a specific user/pass account just for this which is stored in the linked server. Heres the problem:
When I run a SQL Server Agent job to update the azure table from the on prem table using the linked server everything works fine.
When I manually run a sql update statement from an open window in SSMS to do the same everything works fine.
When I use a workflow in the project management software to trigger a Stored Procedure to execute the same code (update Azure from the on prem database) I get the following error:
The OLE DB provider "SQLNCLI11" for linked server "LinkedServerName" reported an error. One or more arguments were reported invalid by the provider.
The operation could not be performed because OLE DB provider "SQLNCLI11" for linked server "LinkedServerName" was unable to begin a distributed transaction.
OLE DB provider "SQLNCLI11" for linked server "LinkedServerName" returned message "The parameter is incorrect.". Error occurred in: STORED_PROCEDURE_NAME[CRLF]Error occurred on line 23
There's nothing on line 23, and like I mentioned earlier, if I manually run the same update statement it works and if I have a SQL Server Agent Job run the same statement it works. Why does it fail when the code is executed by the project management software? Anyone have experience with this?
This is the code to insert the data from on prem into Azure:
INSERT INTO [LinkedServerName].DatabaseName.SchemaName.TableName ([ProjectNumber],[CreateDate],[SyncDate])
I'm not sure about this with Azure but I had a similar issue with a remote server and had to disable promotion of distributed transactions. It might not be the best thing to do in a production environment so read up carefully about the implications of doing this.
I'm only suggesting to try this to narrow down what the real issue is..
Change this setting and test.
I ended up taking a different strategy. We know using a scheduled SQL Agent Job to insert data in to azure works, it just wouldnt work in any script ran by our software and the user it uses to access the on prem database. So I created a SP in the on prem database that the software executes through a built in workflow. The SP executes saving the data to a staging table, then executes the SQL Job, which reads from the staging table and then inserts the data into an Azure table.
Everything worked in the testing environment, but when I replicated all the scripts into production I got a permissions error. After doing a lot of research and testing adjustments to the user I ended up getting it to work by assigning the role TargetServersRole and db_ddladmin to the user in the msdb database and that worked.
ssms screenshot
Below are the two articles that let me to this conclusion:
Article 1
Article 2
I created ms sql database in SSMS 2012. Connected successfully to Azure and trying to deploy db to the cloud.
Encountering following errors:
Please see screen shot
Numerous Usupported property errors — not supported when used as part of a data package
You're likely using a feature not supported in Azure SQL Database. Please refer to this non supported features list to help you pinpoint the problem:
http://msdn.microsoft.com/en-us/library/azure/ff394115.aspx
This happened with me too. In my case ,i changed the schema of a table after creating once for the first time. After deleting that table database deployed correctly. Usually this error occurs when validating schema fails.
Regards
MAnoj Bojja
On my development box, I always run the latest version of SQL Server. I often deploy databases from my dev box to a live/staging area for review or testing. I've done this many times and it has always been a painful process, but I am realizing that I need to find an easier, more reliable and consistent way of performing this basic operation.
I normally use WebMatrix purely for deployment and it's worked fine, but I've been having problems getting it to work on my server for some reason. Consequently, I am seeking an alternative solution.
Creating a SQL dump file would probably work, but it's not an acceptable solution a database contains images and easily exceeds 2 gigs of data which would take forever.
The Import/Export utility fails due to issues with incomplete schema copies, identity inserts and checks. The solutions offered for these issues has failed to work in my particular case.
The Backup and Restore method also fails due to some strange incompatibilities between SQL Server 2008 and 2012. SQL Server 2008 Management Studio throws exceptions during the restore process of a 2012 database. It's odd that this happens, even though I set the compatibility of the database to version 2008.
I haven't tried the Detaching, copying and reattaching files method, but I haven't bothered trying since it would probably fail for the same reasons the backup and restore method did.
Are there other alternatives out there? Also, why is this so unbelievable hard for a task that is so common and important, especially in this day in age of 2013? Get real Microsoft!
We changed our method of deploying and moving databases between servers, instances and versions by adopting the tools from RedGate. They are expensive, but worth it IMHO.
My team creates scripts for ~everything.
Database Creation, Alter, Inserts, etc, etc.
And we write all scripts that check for the existence of things before trying to create them.
Aka, we can run the scripts over and over and get the same results.
And we deploy to different environments by using SqlCmd.exe.
EDIT
See:
http://odetocode.com/blogs/scott/archive/2008/02/02/versioning-databases-views-stored-procedures-and-the-like.aspx
and
http://odetocode.com/blogs/scott/archive/2008/01/30/three-rules-for-database-work.aspx
=============
If that is "too much" then I agree with the other poster, RedGate is your friend.
Points below aside, have you considered the Database Projects within VS2012? they allow you to script off the tables, sp's, triggers, users etc you want, generate sql cmd scripts, make changes and schema compare and version control your database code, I'd certainly recommend it
"Creating a SQL dump file would probably work, but it's not an
acceptable solution a database contains images and easily exceeds 2
gigs of data which would take forever."
Why is this a problem? where are you transferring the file from and to and over what connection?
"The Backup and Restore method also fails due to some strange
incompatibilities between SQL 2008 and 2012. SQL 2008 Management
Studio throws exceptions during the restore process of a 2012
database. It's odd that this happens, even though I set the
compatibility of the database to version 2008"
This shouldn't be an issue if file is created in 2008 prior to restoring. If you create a new DB in your 2008 instance, then take a backup from that and restore it to a 2012 instance with 2008 compatiblity, then you should be able to use it there, back it up from the 2012 instance and restore to 2008 again afterwards.
I am new to replication. I have two sql server 2008 servers running on windows 2008 R2. The servers are in two different locations and on two different domains. I have been able to use aliases to get both "Snapshot publication" and "Transactional Publication" working perfectly. But what I need is "Transactional publication with updatable subscriptions" so if a change is made on either server, the changes are replicated to the other server.
When I run through the New Publication, I get through every page to the very end with no problem but when I click the finish button I get an error. There are three actions and it fails on the first action called "Creating Publication 'xxxx'" The message I get is "SQL Server could not create publication 'xxxx'. an exception occurred while executing a Transact-SQL statement or batch. The distributor has not been installed correctly."
I have searched for an answer and cannot find it. I think this is a permission problem between the two servers but I have no idea how to solve it.
Any help would be appreciated.
In my experience the installation of different types of replication over the top of one that was previously implemented can cause issues.
If able I would suggest clearing all replication and starting from scratch with your new approach.
You have to run a variety of stored procedures to get it completely off the server. Using the GUI only doesn't do nearly as good a job of cleaning everything off.
This guide from Microsoft should get you started.
http://msdn.microsoft.com/en-us/library/ms152757.aspx
Hi My company is deciding for switching its existing application to azure platform (only Sql Part). So we need to upload our db from local to cloud. For migration i came across various tools like
1. cerebrata 's tools
2. SqlAzure Migration wizard
3. Microsoft Sql Data Sync
4. Conventional Script way via management studio.
But all the above tools showed that they have limited capacity. A user cannot work flawlessly on either of the tool.
In cerebrata's tool - the main drawback was its field for Application User Name and Application Key , which my admin havent shared. Also there is manual mapping of fields between azure and local.
Sql Azure Migration wizard - generates scripts and executed too but with lots of error . I was using its version 2.1. Also it very slow. It seems that its a replica of Sql Srvr Mgmt Studio.
Sql Data Sync :- I found it cool as its a MS product but it has limitation too that it only connects with Windows Authentication based local sql server, or you need to explicitly allow the required but. Even after allowing while syncing , I got some Sql Azure Provisioning Error.
4 Sql Srvr Mgmt Studio :- This is most easiest way but requires a lot of manual work to do before actual migration. What i did is that I generated a script of entire db (almost 101123 lines of code for single db) and tried to execute on azure. On the very first time i faced some keyword mismatch error . Finally i removed all line after primary key declaration that With (Padding = Off ....)or something similar and also On Primary then i executed , but still got error on Set Identity Insert On. After doing a lot of hard work in removing unwanted lines waited more than 2 hrs to completed the script remotely, i got no Errors , errors and errors.
So you guys are requested to please suggest me any good alternative stated than above or i am lacking something and can do more with above.
Thanks
Amit Ranjan
I've faced a similar problem recently, running through the options you've listed.
You might give a try to Red-Gate beta for Azure (free for a few months). I found their tools to be quite good for SQL schema and data replication.
Never tried the Azure build myself, though (I migrated tables manually by the time I was told about the offer).