vbscript 字典添加循环产生现有键错误
我只是想构造一个productIDs 字典
dim viewableProductIDs : set viewableProductIDs = CreateObject("Scripting.Dictionary")
do while not rsEntry.EOF
viewableProductIDs.Add rsEntry("ProductID"), true
rsEntry.MoveNext
loop
rsEntry 是一个ADODB 记录集,并且通过详尽的调试打印,我已经确保我的查询确实返回唯一的productIDs 并且记录集没有重复项。但不知何故,vbscript 坚持认为存在重复项。它会很好地添加第一个,但之后所有其余的都会出错。我尝试用检查现有密钥来包围它,它以某种方式认为它们都存在,但第一个存在。最后我只剩下一本只有一个条目的字典。
有谁知道它为什么这样做?
I'm simply trying to construct a dictionary of productIDs
dim viewableProductIDs : set viewableProductIDs = CreateObject("Scripting.Dictionary")
do while not rsEntry.EOF
viewableProductIDs.Add rsEntry("ProductID"), true
rsEntry.MoveNext
loop
rsEntry is a ADODB Recordset and I have made sure, through exhaustive debbug printing, that my query is indeed returning unique productIDs and that the recordset has no duplicates. Yet someohow, vbscript insists on thinking there are duplicates. It'll add the first one fine, but after that it errors out on all the rest. I tried surrounding it with a check for existing key and it someohow thought they all, but the first, existed. Then in the end I'm left with a dictionary with only one entry in it.
Does anyone have any idea as to why it's doing this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
尝试添加
.Value
:说明:
VBScript 有一个称为“默认”属性的概念。例如,该行
的简写
实际上是
Fields
、Item
和Value
都是其各自对象的默认属性 。这里的主要问题在于该链的最后一步:rsEntry("ProductID")
和rsEntry("ProductID").Value
之间的差异。在上面的示例中,由于我没有使用Set
关键字,因此对象引用对于赋值的右侧来说是非法的。由于 rsEntry("ProductID") 计算结果为Field
对象引用,因此解释器将执行下一步并扩展Field
对象的默认属性,值
。如果我这样做了,解释器会将
someObj
设置为Field
对象引用。现在有趣的部分是:
Dictionary
对象可以使用任何类型的值作为其键。使用字符串或数字等简单值更为常见,但使用数组或对象引用是完全合法的。由于对象引用对于Dictionary.Add
方法的第一个参数是合法的,因此解释器不会费心扩展默认属性,而只是使用Field
对象引用作为关键。由于Field
对象引用不会因记录而改变,因此您最终会尝试一遍又一遍地添加相同的键。添加.Value
可以让解释器明确知道您需要的是值,而不是对象。Try adding
.Value
:Explanation:
VBScript has a concept called "default" properties. For instance, the line
really is shorthand for
where
Fields
,Item
, andValue
are all the default properties of their respective objects. The main problem here is in the last step of the chain: the difference betweenrsEntry("ProductID")
andrsEntry("ProductID").Value
. In the above example, since I didn't use theSet
keyword, an object reference would be illegal for the right-hand side of the assignment. SincersEntry("ProductID")
evaluates to aField
object reference, the interpreter takes the next step and expands the default property of theField
object,Value
. If I had donethe interpreter would have set
someObj
to theField
object reference.Now here's the fun part: the
Dictionary
object can use any type of value as its keys. It's more common to use simple values like strings or numbers, but it's perfectly legal to use arrays or object references. Since an object reference is legal for the first argument of theDictionary.Add
method, the interpreter doesn't bother to expand the default property and simply uses theField
object reference as the key. Since theField
object reference doesn't change from record to record, you end up trying to add the same key over and over. Adding.Value
makes it explicitly clear to the interpreter that you want the value, not the object.