SQL CASE 语句和 MINUS
CASE 语句是否会自动中断使用 MINUS 的查询？我将数据集的实时拉取与其之前的缓存进行比较，即使实时拉取中的 CASE 语句返回纯 VARCHAR2 结果，我也会得到它们与缓存表中的静态值之间的类型不匹配，这也存储为 VARCHAR2。
我能想到的唯一其他可能性甚至更小 - 连接（ || ）或单引号中的文字（两者都出现在 CASE 结果中）是否会搞砸？
Is there something about CASE statements that automatically breaks a query that uses MINUS? I'm comparing a live pull of a data set to a previous cache of it, and even though the CASE statements in the live pull return pure VARCHAR2 results, I get a type mismatch between them and the static values in the cache table, which are stored as VARCHAR2 as well.
The only other possibilities I can think of are even less likely - could concatenations ( || ) or literals in single quotes, both of which are present in the CASE results, be fouling things up?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在你的 SELECT 语句中，除了这个 CASE 之外还有其他字段吗？ MINUS 尝试比较整个行，也许其他一些值不匹配。
您是否尝试修剪大小写（
TRIM(CASE foo WHEN..) 以查看是否遗漏了任何内容？所有分支都返回 VARCHAR2 吗？有时，即使一个分支返回数字或日期，它可能会弄乱类型。
In your SELECT statement, do you have any more fields except this CASE? MINUS tries to compare the entire rows, maybe some of the other values aren't matching.
Did you try trimming the case (
TRIM(CASE foo WHEN..) to see if you slipped anything?Are all the branches returning VARCHAR2? Sometimes, even if one branch returns a number or a date, it could mess up the types.