It does sound workable. We don't issue a clear all anywhere in the program until the program is closed. All variables are either declared in the main.prg and are available throughout the app (because for some reason or other they are needed for now to be available everywhere) or are private or local (depending on the requirement) in each prg that declares them. Thanks for idea, I think I'll play around with it!

Tracy

>Tracy,
>
>>We are considering creating some classes to manage data sessions and open tables throughout our app. Has this already been done by someone and is it available? We don't want to incorporate a framework because the app is 10 years old, was recently converted to VFP8 (mostly redone anyway for that). Due to converting the app from FPD26 to VFP8, in almost all cases, the tables are opened before the forms are instantiated and then closed after the form object is destroyed in prg files that call every form and open tables, set any required variables, etc. That is why incorporating a class for table management and data sessions would be a nice tool to implement. Any ideas anyone? Has it already been done?
>
>You may be looking for something more comprehensive and reusable, but one simple idea to help avoid "collisions" of the open table environments of each form is to wrap the code in each of those prgs with the Session class, which automatically gives you a private data session and some simple, but effective, isolation.
>
>Perhaps you would want a first-level subclass of Session that has your preferred environment SET commands in its INIT and a "RunForm" method that accepts as a parameter the PRG name for the form you want to run and issues a DO command to run it. Then, running each form and its associated table-opening PRG in a private data session could be as simple as:
>

>oFormSession = NEWOBJECT("FormSession", "FormSession.prg")
>oFormSession.RunForm("FormABC.prg")
>

>That's just a very simplistic illustration, and there are several other approaches to the same problem that all use Session, but this is just to illustrate that Session can be very valuable in many ways when working with legacy code that might not be properly encapsulated related to its data needs.
>
>You might have other problems, however, including global variables walking on each other or code in the PRGS that does CLEAR ALL or something like that, but maybe this will give you an interesting approach to explore.