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?
Try adding
.Value:Explanation:
VBScript has a concept called “default” properties. For instance, the line
really is shorthand for
where
Fields,Item, andValueare 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 theSetkeyword, an object reference would be illegal for the right-hand side of the assignment. SincersEntry("ProductID")evaluates to aFieldobject reference, the interpreter takes the next step and expands the default property of theFieldobject,Value. If I had donethe interpreter would have set
someObjto theFieldobject reference.Now here’s the fun part: the
Dictionaryobject 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.Addmethod, the interpreter doesn’t bother to expand the default property and simply uses theFieldobject reference as the key. Since theFieldobject reference doesn’t change from record to record, you end up trying to add the same key over and over. Adding.Valuemakes it explicitly clear to the interpreter that you want the value, not the object.