[AccessD] storing last item on the page

A.D.TEJPAL adtp at airtelbroadband.in
Mon Nov 12 07:53:41 CST 2007


    If you do wish to pass the second argument (which is optional) to serve as key, it has to be a string. That is why you correctly used CStr(Me.Page) instead of mere Me.Page. For element pertaining to page 3, key becomes "3", while its index position (i.e. element number is 3). 

    If you retrieve by using col(Me.Page) for page 3, it translates to col(3). It gets you the third element in collection, irrespective of its key. If retrieval is made by using col(CStr(Me.Page)), it will translate to col("3") and get you the element having "3" as its key, irrespective of its position in the collection. In your particular case, being a simple undisturbed collection, the results in either case are identical.

A.D.Tejpal
------------

  ----- Original Message ----- 
  From: Susan Harkins 
  To: Access Developers discussion and problem solving 
  Sent: Monday, November 12, 2007 18:26
  Subject: Re: [AccessD] storing last item on the page


  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. 


More information about the AccessD mailing list