你能发布一些代码和数据来重现这个问题吗?因为这是SWITCH()
在 SQL 代码中,所以我认为 SQL DDL(CREATE TABLE
等)和 DML(INSERT INTO
添加数据)是最合适的:)
[挑剔点:Access 数据库 SQL 没有“布尔”数据类型。它有一个YESNO
可以是NULL
值的数据类型;三值逻辑不是布尔值。]
这是一些 SQL DML(ANSI-92 查询模式语法)来演示它如何按我的预期工作:
SELECT TYPENAME
(
SWITCH
(
NULL, #2009-01-01 00:00:00#,
FALSE, #2009-06-15 12:00:00#,
TRUE, #2009-12-31 23:59:59#
)
);
更改任何“标准”值,该值始终返回为“日期”,即类型DATETIME
。
更新:
该TYPENAME
功能是一个很棒的工具... Access 似乎以不同的方式解释了结果集的整个“列”
的确。因为一列只能是一种数据类型TYPENAME()
,所以行的结果可能会产生误导。混合类型的行值必须“提升”为更高的数据类型。与 Access 数据库引擎一样,该过程是完全不透明的,并且完全没有关于该主题的文档,因此您只需要吸吮它并查看例如
SELECT #2009-01-01 00:00:00# AS row_value,
TYPENAME(#2009-01-01 00:00:00#) AS row_type
FROM Customers
UNION ALL
SELECT 0.5,
TYPENAME(0.5) AS row_type
FROM Customers
分别返回“日期”和“十进制”,但该列是什么?显然,答案是:
SELECT DT1.row_value, TYPENAME(DT1.row_value) AS column_type
FROM (
SELECT DISTINCT #2009-01-01 00:00:00# AS row_value
FROM Customers
UNION ALL
SELECT DISTINCT 0.5
FROM Customers
) AS DT1;
'细绳'?!
...当然,这甚至不是 Access 数据库引擎 SQL 数据类型。因此TYPENAME()
,令人讨厌的是,使用了“最合适”的 VBA 类型的名称。例如:
SELECT TYPENAME(CBOOL(0));
返回“布尔”,尽管如上所述,Access 数据库引擎 SQL 中没有布尔数据类型。和
SELECT TYPENAME(my_binary_col)
返回“字符串”。请注意,相同的 VBA 映射限制适用于CAST
函数(又一个烦恼),例如,没有“强制转换为BINARY
”函数,并且CDEC()
自 Jet 4.0 以来该函数仍然损坏:(