错误警告：带有Like运算符的DAO 3.6 FindFirst [英] Bug warning: DAO 3.6 FindFirst with Like operator
问题描述
微软承认这有一个错误，但错误比他们说的更糟糕。
事实证明，如果你使用Like操作符而没有通配符
快照类型记录集，可能发生各种奇怪的，不受欢迎的事情。
当你需要像匹配列表那样的情况时会出现这种情况
条件，一些根据微软的说法，它的缺点是它会处理所有没有
通配符的表达式，就好像它们后跟*一样。事实上，我发现任何单个
字符表达式，例如B字符。会匹配一切！基本上，这个
归结为你应该永远不要在快照上使用FindFirst
记录集，除非你确定表达式--will-至少包含一个
通配符。
Steve Jorgensen< no **** @ nospam.nospam>写在
新闻：d1 ******************************** @ 4ax.com：
微软承认这有一个错误，但错误比他们说的更糟糕。
事实证明，如果你使用Like运算符如果在快照类型记录集上没有通配符，就会发生各种奇怪的，不受欢迎的事情。当你需要像匹配条件列表这样的东西时会出现这种情况，其中一些是完全匹配的。
根据微软的说法，错误是它会处理所有表达式
没有通配符，就好像它们后跟*一样。事实上，我发现任何单个字符表达，例如B等。将匹配所有内容！
基本上，这归结为你永远不应该使用在快照记录集上使用LikeFirst，除非你确定
表达式 - 将包含至少一个通配符字符。
当你要求它时你想要它做什么：
..FindFirst" fldDescription LIKE''B' '&b; b $ b我想知道我们怎么可能会耸耸肩说MS不能
预测编码的每一个特性！，我们中有多少人会说，
Bug！响应这个。
我会说两个中的第一个。
我注意到ADO
（
..CursorType = adOpenStatic
..LockType = adLockReadOnly
）
找不到任何记录：
..找到'fldDescription LIKE''B''"
并将记录指针移动到.EOF
（非常合适IMO）
除非有一个值为
" B"的记录。 （仅）
在搜索字段中
，在这种情况下它是
" found"记录。
-
Lyle
（电子邮件参考 http://ffdba.com/contacts.htm ）
no****@nospam.nosp am（Steve Jorgensen）在
< d1 *中写道*******************************@4ax.com>：
Microsoft承认这有一个错误，但错误比他们说的更糟糕。
事实证明，如果你在快照类型记录集上使用没有通配符的Like运算符，各种奇怪的，不受欢迎的事情都可能发生。当你需要像匹配条件列表那样的情况时会出现这种情况，其中一些是完全匹配的。
我不太明白没有星号的LIKE的使用。
这不等于= ？
我使用BuildCriteria构建我的所有WHERE子句，所以我
从不代码覆盖exactl和LIKE，这是唯一的
场景我可以想到你在没有星号的情况下使用LIKE的位置。
根据微软的说法，它的缺点是它会在没有通配符的情况下处理所有
表达式，就好像它们一样接下来是*。事实上，我发现任何单个字符表达式，如B
都将匹配所有内容！基本上，这归结为
除非你确定表达式 - 将包含至少一个
通配符，否则你不应该在快照记录集上使用FindFirst
。 blockquote>
好吧，D''哦！
为什么有人会练习使用LIKE除了
通配符，除了编码懒惰？
-
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
2004年1月19日星期一18:09:30 GMT， dX ******** @ bway.net.inva 盖子（David W.
Fenton）写道：
no **** @ nospam.nospam（Steve Jorgensen） ）写在
< d1 **************** ****************@4ax.com>：
微软承认这个错误，但错误比
他们说。
事实证明，如果你在快照类型记录集上使用不带通配符的Like运算符，就会发生各种奇怪的，不受欢迎的事情。当你需要像匹配条件列表那样的情况时会出现这种情况，其中一些是完全匹配的。
我不太明白没有星号的LIKE的使用。
它不等同于= ？
是的，确切地说。就我而言，我有一个关于如何从导入表中导入
列的规则列表，这些列可能因月而异。对于某些规则，
我知道确切的名称，对于某些规则，我知道
名称的不变部分。我有一个规则表，其中匹配条件是Like表达式，
如果匹配是确切的字段名称，则没有通配符。
这应该是想要做的事情是对的吗？
我使用BuildCriteria来构造我所有的WHERE子句，所以我从来没有代码覆盖exactl和LIKE，这是唯一的
场景我可以想到你在没有星号的情况下使用LIKE的位置。
根据微软的说法，它的缺点是它会将没有通配符的所有
表达式视为它们之后是*。事实上，我发现任何单个字符表达式，如B
都将匹配所有内容！基本上，这归结为
除非你确定表达式 - 将包含至少一个
通配符，否则你不应该在快照记录集上使用FindFirst
。 blockquote>
好吧，D''哦！
为什么有人会练习使用LIKE，除了使用
通配符，除了编码懒惰？
见上文。喜欢应该表现得像=对于没有通配符的表达式。为什么
当我有一个
标准列表时，我不应该期望利用这个事实，有些确切，有些则没有？就我而言，编码懒惰
这种b $ b可能是一件好事。使用 - 应该是内置的
的功能，而不是必须编写自己的代码来复制它。现在，
我承认，我最近一直在提倡做其他事情时改进代码
清晰度并设计常见的程序员错误，但这不是其中之一
个案。
Microsoft acknowledges a bug with this, but the bug is worse than they say.
It turns out that if you use the Like operator without a wildcard on a
snapshot type recordset, all sorts of wierd, undesirable things can happen.
This situation can arise when you need something like a list of match
conditions, some of which are exact matches.
According to Microsoft, the bug is that it will treat all expressions without
wildcards as if they are followed by *. In fact, I found out that any single
character expression such as "B" will match everything! Basically, what this
comes down to is that you should never use FindFirst with Like on a Snapshot
recordset unless you are certain the expression -will- contain at least one
wildcard character.
解决方案Steve Jorgensen <no****@nospam.nospam> wrote in
news:d1********************************@4ax.com:
Microsoft acknowledges a bug with this, but the bug is worse than they
say.
It turns out that if you use the Like operator without a wildcard on a
snapshot type recordset, all sorts of wierd, undesirable things can
happen. This situation can arise when you need something like a list of
match conditions, some of which are exact matches.
According to Microsoft, the bug is that it will treat all expressions
without wildcards as if they are followed by *. In fact, I found out
that any single character expression such as "B" will match everything!
Basically, what this comes down to is that you should never use
FindFirst with Like on a Snapshot recordset unless you are certain the
expression -will- contain at least one wildcard character.
What do you want it to do when you ask it to:
..FindFirst "fldDescription LIKE ''B''"
I wonder how may of us would shrug our shoulders and say, "MS cannot
predict every peculiarity of coding!", and how many of us would say,
"Bug!" in reponse to this.
I would say the first of the two.
I note that ADO
(
..CursorType = adOpenStatic
..LockType = adLockReadOnly
)
does not find any records for:
..Find "fldDescription LIKE ''B''"
and moves the record pointer to .EOF
(quite properly IMO)
unless there is a record with the value
"B" (only)
in the searched field
in which case it
"finds" that record.
--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)
no****@nospam.nospam (Steve Jorgensen) wrote in
<d1********************************@4ax.com>:
Microsoft acknowledges a bug with this, but the bug is worse than
they say.
It turns out that if you use the Like operator without a wildcard
on a snapshot type recordset, all sorts of wierd, undesirable
things can happen. This situation can arise when you need
something like a list of match conditions, some of which are exact
matches.
I don''t quite understand the use of LIKE without an asterisk.
Wouldn''t it be equivalent to "=" ?
I use BuildCriteria for constructing all my WHERE clauses, so I
never code to cover both exactl and LIKE, which is the only
scenario I can think of where you''d use LIKE without the asterisk.
According to Microsoft, the bug is that it will treat all
expressions without wildcards as if they are followed by *. In
fact, I found out that any single character expression such as "B"
will match everything! Basically, what this comes down to is that
you should never use FindFirst with Like on a Snapshot recordset
unless you are certain the expression -will- contain at least one
wildcard character.
Well, D''oh!
Why would anyone make a practice of using LIKE except with a
wildcard, except coding laziness?
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
On Mon, 19 Jan 2004 18:09:30 GMT, dX********@bway.net.invalid (David W.
Fenton) wrote:
no****@nospam.nospam (Steve Jorgensen) wrote in
<d1********************************@4ax.com>:Microsoft acknowledges a bug with this, but the bug is worse than
they say.
It turns out that if you use the Like operator without a wildcard
on a snapshot type recordset, all sorts of wierd, undesirable
things can happen. This situation can arise when you need
something like a list of match conditions, some of which are exact
matches.
I don''t quite understand the use of LIKE without an asterisk.
Wouldn''t it be equivalent to "=" ?
Yes, exactly. In my case, I have a list of rules for how to import from
columns in an import table that can vary from month to month. For some rules,
I know the exact name, and for some rules, I know an invariant part of the
name. I have a table of rules where the match condition is a Like expression,
and if the match is an exact field name, there are no wildcard characters.
This should be a valid thing to want to do, right?
I use BuildCriteria for constructing all my WHERE clauses, so I
never code to cover both exactl and LIKE, which is the only
scenario I can think of where you''d use LIKE without the asterisk.According to Microsoft, the bug is that it will treat all
expressions without wildcards as if they are followed by *. In
fact, I found out that any single character expression such as "B"
will match everything! Basically, what this comes down to is that
you should never use FindFirst with Like on a Snapshot recordset
unless you are certain the expression -will- contain at least one
wildcard character.
Well, D''oh!
Why would anyone make a practice of using LIKE except with a
wildcard, except coding laziness?
See above. Like should act like "=" for expressions with no wildcards. Why
should I not expect to take advantage of this fact when I have a list of
criteria, some exact, and some not? As far as I''m concerned, coding laziness
of this sort can be a -good- thing. Use the functionality that -should- be
built in instead of having to write your own code that duplicates that. Now,
I admit, I''ve recently been advocating doing otherwise when it improves code
clarity and designs out common programmer errors, but this is not one of those
cases.
这篇关于错误警告：带有Like运算符的DAO 3.6 FindFirst的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
