2 Replies Latest reply on Mar 24, 2015 7:19 AM by edpod2101

    Virtual Lists in a multi-user application


      VL's are a great way to provide flexible and dynamic pick lists.  So far I haven't encountered any problems but I'm concerned about this as the application gets more users.  I have a few VL's that are created via an OnRecordLoad script that builds the list based on specific values entered by the user.  I'm creating the VL by initializing the records in the list table every time I build the VL.  My concern is that at some point users will access the same function (different records) and the same VL. 


      Ideally, each user would have their own version of the list table and therefore never collide with another user accessing the same VL.  But I didn't build it this way.  I'm not sure how I would do that.  Currently each VL has it's own table containing a number or records sufficient to handle the value list.


      Any advice?

        • 1. Re: Virtual Lists in a multi-user application

          Are these lists Virtual or not?  You said they are being stored in a table and that means they are not virtual.  For them to be virtual, they need to be globally stored ($$Variable).  You can have a table that makes calculation calls to pull data from a global variable and I do that a lot.  It works really well and is very fast since the data is not stored anywhere.  You need to make sure you are not storing your virtual lists.  Big time speed penalty hits and the issue of multiple people seeing the same data.  If you use global variables, then no such issues. 

          • 2. Re: Virtual Lists in a multi-user application

            False alarm.  It turns out that I am storing my values in global variables, as you stated.  It's been a while since I looked at the table structures.  Somehow I got it in my head that I was storing the data in the tables.  Thanks for getting me grounded.  Time to get back on the memory supplements.