避免Access和SQL Server的空值冲突

核心提示： 图BNz返回一个实际的值，而不是容易使人产生误解的空值第二个表达式返回零长度的字符串来取代空值：WithoutOptional: Nz([Region])虽然这样为用户提供的信息较少，避免Access和SQL Server的空值冲突(3)，但却有效防止了在后续的表达式中使用空值，从而避免数

图B

Nz返回一个实际的值，而不是容易使人产生误解的空值第二个表达式返回零长度的字符串来取代空值：

WithoutOptional: Nz([Region])

虽然这样为用户提供的信息较少，但却有效防止了在后续的表达式中使用空值，从而避免数据库出错。图C显示的新表达式证明了这一点。

图C

表达式可能不能像预期的那样处理空值

两个表达式都直接或间接依赖于Region字段中的值。第一个表达式直接引用Region字段：

RegionString: IIf([Region]="","N/A",[Region])

只看表达式，你可能认为结果记录集的每个字段中都应该出现一个字符串。图D展示了实际结果，它和你设想的不符，并不是每个字段都包含一个字符串。事实上，只有在字段包含零长度字符串（""）的前提下，表达式才会返回字符串"N/A"。我们知道，这些看似空白的字段包含空值，而不是零长度的字符串。但是，错误是可以理解的，也是能避免的。

图D

遇到空值时，用Nz返回值而不是错误

下一个表达式也引用了Region值，只是通过Nz函数的结果来间接地引用：

WithoutOptionalString: IIf([WithoutOptional]="","N/A",[WithoutOptional])

这样一来，任何空值都可用一个更确切的值来表示，并在后续任何表达式中进行求值。如图D所示，表达式在处理空白Region字段时没什么问题。只有“未预计到”或者“未知”的空值才会导致问题。