1.字符型字段后端空格有時壓縮﹐有時無壓縮,不管存進時是否已經壓縮﹔不象SQLSERVER那樣可在系統設置該特性(我用的字段屬性是UNICODE,否則更慘)。
2.JET SQL的WHERE 條件有時受字段后端空格影響。
如﹕[表1]的字段[編號]的值為"AAA ",[名稱]的值為"NNN"。
'SELECT * FROM [表1] WHERE [編號]="AAA";' ,一般可得到該記錄﹐但有時無該記錄。
3.JOIN 關聯時上述不穩定更明顯。總不能在所有SQL語句中手工壓縮吧﹕ 'SELECT * FROM [表1] WHERE LTRIM(RTRIM([編號]))="AAA";' (無問題) 'SELECT [表1].*,[表2].[某值] FROM [表1] AS A INNER JOIN [表2] AS B ON LTRIM(RTRIM(A.[編號]))=LTRIM(RTRIM(B.[編號]));' (無問題) ---當一個項目已經完成時!?
以上均在ACCESSS中直接測試!
4.有時字段中確實有數值(整數)﹐但用DAO讀出竟為0,換ADO又可讀出該數值。
2.JET SQL的WHERE 條件有時受字段后端空格影響。
如﹕[表1]的字段[編號]的值為"AAA ",[名稱]的值為"NNN"。
'SELECT * FROM [表1] WHERE [編號]="AAA";' ,一般可得到該記錄﹐但有時無該記錄。
3.JOIN 關聯時上述不穩定更明顯。總不能在所有SQL語句中手工壓縮吧﹕ 'SELECT * FROM [表1] WHERE LTRIM(RTRIM([編號]))="AAA";' (無問題) 'SELECT [表1].*,[表2].[某值] FROM [表1] AS A INNER JOIN [表2] AS B ON LTRIM(RTRIM(A.[編號]))=LTRIM(RTRIM(B.[編號]));' (無問題) ---當一個項目已經完成時!?
以上均在ACCESSS中直接測試!
4.有時字段中確實有數值(整數)﹐但用DAO讀出竟為0,換ADO又可讀出該數值。
数据库认为它不是空格(ASCII=32),于是产生怪事。
但也有邪门的事:
ADO+SQLServer,用TADOQuery.locate 找某字段等于某字符串的记录竟然有也找不到(在一个数据库环境中可以,在另一数据库环境不行),用While Not EOF Do 循环一个一个找才找到。
fyje(冬原) :50fen