>>>If anyone did that, we'd have a nice thread about it, and about problems it would create. While theoretically limited only by 32767, practically it'd be quickly limited with system's capacity. Each opened table takes resources, needs buffers, handles, etc - and having thousands of tables open simultaneously would surely bring the system to its knees really soon.
>>>
>>>Next thing you know, someone would ask "why are you doing this", and we'd have another trip to Kia via Saturn Diesel.
>>
>>LOL! Oddly enough, I was involved with a system where instead of taking private data sessions, they went with everything in the default data session and generated unique names for the cursors based on the customer id.
>>
>>This LIMITED them to only 32767 instead of 32767 x # of private data sessions, but it also opened up a terrible risk. If the wrong work area was selected customer A information would get cross with customer B information. That's not bad, but in this case it was a medical system and it would have killed someone had we not caught it during alpha testing.
>>
>>Everything is possible without standards and that's not the good thing everyone seems to think it is.
>
>I was involved in a similar setup: everything was secure in private DS with its unique alias, but each DS/Form opened up between 200 and 600 work areas on about 150 tables. NOT the most performant system for exactly the reasons Fabio mentioned <g>. Rerouting all lookup accesses to objects living in DS 0 cut about one quarter of the number of tables open in each private DS, and rewriting the combo base classes to work of arrays filled in DS 0 dropped the number even more. Made it bearable - so use private and common DS together...

That's nice. I have another derivative for you. Conditionally private datasessions. When a form is called from the menu, it's PDS. When the same form is called as a picklist from within another form it's DDS.