如何由Sybase向SQL Server移植数据库

尽管Sybase和SQL Server之间的一些差别是相当大的,例如Sybase数据库管理系统中的存储过程在SQL Server就不能被编译,而其它差别则不太大。在完成这一转换前,对脚本文件和存储过程中编程逻辑的行为和结果进行测试是很有必要的。

在下面的部分中,我们将讨论这二种数据库系统之间的一些主要的不同点,在移植的规划阶段,我们必须仔细研究这些区别。

数据兼容模式

对SQL Server 2000和Sybase之间的一些兼容性差别的一个临时性解决方案是改变SQL Server中的数据库兼容性级别,使之与Sybase相符。为此,我们可以使用sp_dbcmptlevel存储过程。

下面表中的语句和结果显示出不同版本数据库之间的差别:

注意:

1.当兼容性模式被设置为70时,下面的词汇不能被用作对象名和标识符:BACKUP、DENY、PRECENT、RESTORE和TOP;

2.当兼容性模式被设置为65时,下面的词汇不能被用作对象名和标识符:AUTHORIZATION、CASCASE、CROSS、DISTRIBUTED、ESCAPE、FULL、INNER、JOIN、LEFT、OUTER、PRIVILEGES、RESTRICT、RIGHT、SCHEMA和WORK。

下面是sp_dbcmptlevel的语法:

sp_dbcmptlevel [[@dbname=] name][,[@new_cmptlevel=]version]

@dbname是用于检查和改变兼容性水平的数据库名字;

@new_cmptlevel决定数据库被设置的兼容性水平(将它设置为70、65、60,缺省值为NULL)。

例如:

sp_dbcmptlevel pubs

这一行代码返回下面的结果:

The current compatibility level is 70.(当前的兼容性级别为70)

现在我们来看一下另外一个例子:

sp_dbcmptlevel pubs, 65

它返回如下的结果:

DBCC execution completed. (DBCC执行结束)

果DBCC打印出错误信息,则需要与系统管理员联系。我们可以使用rerunsp_dbcmptlevel验证pubs数据库是否修改得正确:

sp_dbcmptlevel pubs

它返回下面的结果:

The current compatibility level is 65(当前的兼容性级别为65)

除了上面的例子外,兼容性级别的差别还扩展到了保留字。Sybase和SQL Server都有许多不能被用作数据库中对象名字的的保留字,二种产品的保留字相似,但并不完全相同。

由于能够在Sybase中使用的对象可能不能在SQL Server中使用,这一问题使得由Sybase向SQL Server的移植凭添了许多困难。下面是在SQL Server中是保留字,而在Sybase中不是保留字的词汇清单。

注意:名字为下列清单中词汇的Sybase数据库中的对象在移植到SQL Server数据库时必须换为其它名字。

BACKUP COLUMN COMMITTED CONTAINS CONTAINSTABLE

CROSS CURRENT_DATE CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER

DENY DISTRIBUTED FILE FLOPPY FREETEXT

FREETEXTTABLE FULL IDENTITYCOL INNER JOIN

#p#

事务管理模式

Sybase SQL Server

Set chained [ on : off ] Set implicit_transactions [on : off ]

在Sybase中使用下面的代码判断事务模式:

SELECT @@tranchained
GO

下面是可能返回的结果:

0表明使用的是非链锁式事务模式

1表明连接运行在链锁模式下

在SQL Server中使用下面的代码判断事务模式:

IF (@@options & 2) > 0
PRINT on
ELSE
PRINT off

下面是可能的返回结果:

0 off
>0 on

隔离水平

在一个关系数据库这样的多线程应用软件中,数据库引擎对运行的进程间的数据是如何被隔离的管理是非常重要的,在表示隔离水平时,Sybase和SQL Server的语法是不同的。下面的表格表明了Sybase和SQL Server在表示隔离水平时的差别。

Sybase SQL Server

0 READ UNCOMMITTED
1 READ COMMITTED
2 REPEATABLE READ
3 SERIALIZABLE

游标语法

二种产品中存储过程的创建和执行基本相似,但在移植时,游标语句中的一些例外是我们应当注意的。下面是一个例子:

  CREATE PROCEDURE sql_cursor AS
  DECLARE @lname char(20), @fname char(20)
  DECLARE mycursor CURSOR FOR
  SELECT au_lname, au_fname FROM authors
  OPEN mycursor
  FETCH FROM mycursor INTO @lname, @fname
  WHILE @@ FETCH_STATUS = 0
  /* Sybase数据库使用@SQLSTATUS而不是@@ FETCH_STATUS */
  BEGIN
  FETCH FROM mycursor INTO @lname, @fname
  /*
  ** 这里应当是一些业务逻辑
  */
  END
  CLOSE mycursor
  DEALLOCATE /* Sybase数据库在这里需要CURSOR这个词 * / mycursor
  
  
  Sybase SQL Server
  
  Fetch命令执行成功 0 0
  Fetch命令执行失败 1 -2
  没有可存取的记录了 2 -1

#p#

退回触发器

SQL Server中不存在这个命令,因此在向SQL Server移植时,使用了ROLLBACK TRIGGER命令的Sybase存储过程必须被进行修改。在修改带有触发器的数据库表中的数据时,使用ROLLBACK TRIGGER命令容易引起误解,一个ROLLBACK TRIGGER命令只退回触发器以及触发触发器的数据修改,如果已经被提交了,则事务的其它部分会继续,被写到数据库中。因此,事务中的所有语句可能没有被成功地完成,但数据已经被提交了。

下面是Sybase数据库中一个使用ROLLBACK TRIGGER的样例触发器:

CREATE TABLE table1 (a int, b int)
GO
CREATE TRIGGER trigger1 on table1 FOR INSERT
AS
IF EXISTS (SELECT 1 FROM inserted WHERE a = 100)
BEGIN
ROLLBACK TRIGGER with RAISERROR 50000 Invalid value for column a
END
INSERT INTO table2
SELECT a, GETDATE() from inserted
RETURN
GO

在上面的代码中,除非a = 100,则所有插入table1的数据也被作为审计行插入table2中,如果a = 100,ROLLBACK TRIGGER命令被触发,而INSERT命令没有被触发,批命令的其它部分继续执行,这时会出现错误信息,表明在一个INSERT命令中出现了错误。下面是所有的INSERT命令:

BEGIN TRAN
INSERT INTO table1 valueS (1, 1)
INSERT INTO table1 valueS (100,2)
INSERT INTO table1 valueS (3, 3)
GO
SELECT * FROM table1

在执行这些命令后,table1和table2二个数据库表将各有2个记录,Table1表中的值为1,1以及3,3,由于ROLLBACK TRIGGER命令,第二个INSERT命令没有执行;Table2表中的值为1,(当前日期)以及3,(当前日期),由于当a = 100时ROLLBACK TRIGGER被触发,触发器中的所有处理被中止,100没有被插入到Table2表中。

在SQL Server中模拟这一操作需要更多的代码,外部的事务必须与保存点同时使用,如下所示:

CREATE trigger1 on table1 FOR INSERT
AS
SAVE TRAN trigger1
IF EXISTS (SELECT * FROM inserted WHERE a = 100)
BEGIN
ROLLBACK TRAN trigger1
RAISERROR 50000 ROLLBACK
END
INSERT INTO table2
SELECT a, GETDATE() FROM inserted
GO

这一触发器以一个存储点开始,ROLLBACK TRANSACTION只退回触发逻辑,而不是整个事务(规模要小于Sybases数据库中的ROLLBACK TRIGGER语句。对批命令的修改如下:

BEGIN TRAN
SAVE TRAN save1
INSERT INTO table1 valueS (1, 1)
IF @@error = 50000
ROLLBACK TRAN save1
SAVE TRAN save2
INSERT INTO table1 valueS (100, 1)
IF @@error = 50000
ROLLBACK TRAN save2
SAVE TRAN save3
INSERT INTO table1 valueS (3, 3)
IF @@error = 50000
ROLLBACK TRAN save3
COMMIT TRAN

我们可以发现,改变不可谓不大。由于ROLLBACK TRIGGER命令能够使任何批命令不能成功执行,因此在移植的SQL Server存储过程代码中必须包括另外的逻辑,根据ROLLBACK TRIGGER的使用,这可能是一个艰巨而必要的任务,没有什么捷径可走。如果在移植后所有的ROLLBACK TRIGGER命令被改变为ROLLBACK TRANSACTION,触发器的执行也会发生变化,因此我们应当十分小心。

【编辑推荐】

  1. Sybase数据备份之BCP用法简介
  2. 如何设置Sybase的用户权限来处理进程
  3. 在Sybase Adaptive Server Enterprise中保护数据隐私

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/229868.html<

(0)
管理的头像管理
上一篇2025-04-18 23:30
下一篇 2025-04-18 23:31

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注