兼容性处理
由于 MS SQL Server 版本众多,且云上的版本与本地版本也有差异,所以能不能迁移成功,主要看能不能找到并解决数据库之间的兼容性问题。
下面将详细的介绍笔者碰到的兼容性问题。
兼容性处理详情
数据库中设置的用户不存在
兼容性检查的报告显示下面的信息:
Error SQL71564: Error validating element [xxxx]: The element [xxxx] has been orphaned from its login and cannot be deployed.
其中的xxxx是数据库中设置的用户名。
这个错误的原因是用户被定义在本地的 SQL Server 中,数据库中一旦使用用户的信息,把数据库迁移到云上后,就找不到对应用户的定义了,所以就需要移除本地用户的信息。
不用担心数据库的访问问题,因为完成迁移后,你可以使用刚才创建的 Azure SQL Server 账号访问数据库。当然你也可以为一个数据库创建独立的访问账号,具体操作请参考 MSDN。
不支持Extended Property
兼容性检查的报告显示下面的信息:
One or more unsupported elements were found in the schema used as part of a data package.
Error SQL71564: The element Extended Property: [dbo].[xxxx].[MS_Description] is not supported when used as part of a data package (.bacpac file).
其中的xxxx是数据库中一张表的名称。
这下可麻烦了,不支持 Extended Property!在笔者的数据库中有好几处都用到了这个特性。怎么办?只好一遍又一遍的查看程序。最后发现程序中没有使用这个特性,好像当时只是有人用它做了一些说明。还好,最终的结论是可以移除的。
创建 clustered index
兼容性检查的报告显示下面的信息:
One or more unsupported elements were found in the schema used as part of a data package.
Error SQL71564: Table Table: [dbo].[xxxx] does not have a clustered index. Clustered indexes are required for inserting data in this version of SQL Server.
其中的xxxx是数据库中一张表的名称。
需要给表创建 clustered index,这可不是一件小事情,因为任何对表的修改都可能会影响到程序逻辑,怎么办呢?网上的朋友们早就有了比较靠谱的解决方案,就是给表添加一列用来做 clustered index,这样原来表中的列就没有发生变化:
ALTER TABLE [xxxx] ADD
RowId int NOT NULL IDENTITY (1, 1) PRIMARY KEY CLUSTERED
GO