Susan Harkins
ssharkins at gmail.com
Mon Nov 12 06:56:20 CST 2007
I worked through this a little last night and you're right. I totally missed the logic there -- thanks. But I do have a question for you. > This means that "1" to "4" get stored as the key string values for > elements "LV-1" to "LV-4" respectively of the collection. In this state, > the index position of the four elements is 1 to 4. The results fetched by > the following two statements for page 3 will be identical: > > (a) Syntax: col(CStr(Me.Page)) - using key: > col("3") fetches "LV-3" > > (b) Syntax: col(Me.Page) - using index position: > col(3) also fetches "LV-3" > > If, for some reason (although not likely in this particular case), > second element of collection were to be removed, and then re-added as > "LLVV-2" with key "2" for page 2, the existing 3rd & 4th elements will > move up to 2nd & 3rd positions respectively, while the newly added element > "LLVV-2" will occupy the last i.e. fourth position (unless you take > special care to specify its position in Add statement by making use of > optional third & fourth arguments). ======The whole point of using Me.Page as the key value was to make sure there was an identical match when I retrieved the value using Me.Page. I see where storing Me.Page as the key is unnecessary in this particular case. But wouldn't storing Me.Page as the key keep the above from happening? It sounds like the key value is retrieving by position and not by actual value? Susan H.