Sybase程序设计中极易造成误解的内部规则

SYBASE 数据库是当今在UNIX环境下最为流行的大型数据库之一，本人在SYBASE下开发和维护软件的过程中，发现了一些SYBASE的内部规则，在程序设计中极易造成误解，而达不到预期的目的。下文将本人所发现的几个问题及其解决办法叙述如下：

◆1、在sybase11.5中，组合两个定长的 char(x)="aaa",char (y)="bbb"; char(x) char(y)!="aaabbb"

declare @val_1 char(8)

declare @val_2 char(1)

select @val_2 = 'x'

select @val_1 = "0000"

select @var_1= @val_1 @val_2

select @var_1

我们期望的结果为0000x， 而实际上其结果为0000。

解决方法一：当我们将"select @var_1=@val_1 @val_2"，改为"select @var_1=rtrim(@var_1) @var_2"时，我们便看到了我们所期望的结果。为什么呢？在有的SYBASE版本中存储一个char(n)时，在其真实值后补上了相应数量的空格，在本例中，存储在@var_1中的是0000 （在0000后有四个空格）。你可以加上如下两句来验证：

declare @val3 char(10)

select @val3 = @val_1 @val_2

select @val3

这时你会得到的结果为0000 x （在0000后有四个空格）。

解决方法二：将char 改为 varchar 也可以达到预期的目的。

◆2、用alter table 增加表结构时，虽然用sp_recompile tablename 重编译了所影响的数据库对象，但在运行某些包含"select * from tablename"的存储过程时，存储进程仍不认识用alter table 增加的列。例：

1> create table tmp(aa int,bb int)

2> go

1> create table b_tmp(aa int,bb int)

2>go

1> create proc tmpstore

2> as

1> insert b_tmp select * from tmp

2> return

3> go

1> alter table tmp add cc char(8) null

2> go

1> alter table b_tmp add cc char(8) null

2> go

1> sp_recompile tmp

2> go

1>insert tmp values(12,1234,"abcdefg")

2>go

1> exec tmpstore

2> go

1> select * from b_tmp

2> go

aa　　　　　　bb　　　　　　cc

----------- ------------- -------------

12　　　　　　1234　　　　　NULL

为什么cc字段是NULL,而不是"abcdefg"? 用alter table 增加表结构后，包含"select * from tablename"的存储过程，用sp_recompile tablename 重编译仍不能使新增的列被存储过程所识别。解决办法只有一个：删了重建。