特殊的数据类型
"特殊"的数据类型...
SQL_NULL 数据类型
SQL_NULL类型保存任何数据,但只有一个状态:NULL或 NOT NULL。这不是作为一种用于声明表字段,PSQL变量或参数的描述的数据类型。它被添加到支持无类型的使用表达式中的参数涉及的IS NULL断言。
求值问题发生时可选的过滤器可用于编写以下类型的查询
WHERE col1 = :param1 OR :param1 IS NULL
经过API级的处理,查询会像这样:
WHERE col1 = ? OR ? IS NULL
这是开发人员编写一个SQL查询一种情况,认为:参数是一个变量,它可以指两次。然而,在 API 级别,该查询包含两个分离的且独立的参数。服务端不能判定第二个参数的类型,因为它来自于IS NULL 的关联.
所述SQL_NULL数据类型解决了这个问题。每当引擎在查询中遇到'? IS NULL'断言,它分配SQL_NULL类型的参数,这将表明参数仅为"nullness"和数据类型或值不需要被处理。
下面的示例演示了其在实践中的运用。它假定两个命名的参数 — — 比如说:SIZE和:COLOUR — — 哪个可能,例如,从屏幕上文本字段或下拉列表中取值。每个命名参数对应于查询中的两个位置参数。
SELECT
SH.SIZE, SH.COLOUR, SH.PRICE
FROM SHIRTS SH
WHERE (SH.SIZE = ? OR ? IS NULL)
AND (SH.COLOUR = ? OR ? IS NULL)
解释这里发生了什么假定读者熟悉Firebird的API 和传递参数在 XSQLVAR 结构中 — — 在表面下会发生什么,不写驱动程序或应用程序的通信使用"赤裸"的 API的人是不会感兴趣的.
应用程序将参数化查询传递到服务端在通常的位置?—构成。对"相同"参数不能合并成一个,两个可选的过滤器,例如,四个位置参数需要:一个用于每一个吗?在我们的例子中。
对isc_dsql_describe_bind()的调用后,第二个和第四个参数据SQLTYPE将设定为SQL_NULL,Firebird不知道他们的特殊关系对于第一个和第三个参数:责任完全在于应用方。
一旦大小和颜色的值已经由用户设置(或未设置)并且查询即将被执行时,每对XSQLVARs必须作如下填写:
用户已经提供了一个值
第一个参数(值进行比较):设置*SQLDATA为所提供的值和*SQLIND为0(对于NOT NULL)
第二个参数(NULL测试):设置SQLDATA为空(NULL指针,而不是SQL NULL)和* SQLIND为0(对于NOT NULL)
用户留下该字段为空
这两个参数:设置SQLDATA为空(NULL指针,而不是SQL NULL)和* SQLIND为-1(表示NULL),换句话说:这个值比较参数始终设置如常。该SQL_NULL参数设置是相同的,除了SQLDATA始终保持为空。