>Ed,
>
>Yes, it does sound like a lot of work, and I know that once you come with a solution and class it you never have to worry about doing it again, but I guess my question now would be "why bother?" Is using the DE such a great advantage that I'd want to jump thru all these hoops just so I could use it? I guess I don't know what the benefits are (if any) to using the DE?
>

It simplifies much of the design-time stuff, like using drag and drop screen design, and it really is necessary to make use of private datasessions. As to hoops, again, most commercial frameworks have all the necessary code in place to use the DE. Once you have the necessary hooks in place, it's easier to use the DE for implementing your application; drag the tables and views that you want onto the DE, and then simply drag fields or views onto the form to get their pre-defined controls set up.

>Bonnie
>
>
>>I use the DE in forms, and have code in my framework that runs in the DE.BeforeOpenTables event which goes and fixes the paths in the DE objects (DataEnvironment.Cursor.DataBase and DataEnvironment.Cursor.CursorSource) before the actual tables get opened; I pick up the actual data paths before anything ever gets opened from the station configuration entries (depending on which of my applications is looked at, there's either a registry entry, a command line parameter passed in by the shortcut that starts the app, or a set of records in the system's main configuration table that specify where the user is supposed to look for data files) and store the base path for data in a property of my application object. I use that app object property to fix things before my forms try to open tables and views.
>>
>>It may sound like a lot of work, but it really isn't - develop the strategy once, and build it into your base form class, so that every form derived from it inherits the behavior that you need. That's a big part of OOP. The development curve can be reduced even further by using a framework that already handles the behavior the way you want it done, or can be extended to do what you want easily.
>>
>>>Bonnie
>>>
>>>>Bonnie, the reason that opening the tables in the main improves the performance of the forms is that VFP can reduce or eliminate the most costly (in terms of time) part of the USE statement; searching the directory for the appropriate file entries and performing the low-level file open that creates the reference used by VFP to 'talk' to the file. Once a file is open, a handle (a reference) for the file exists, and VFP can duplicate that reference rather than go through the whole process of redoing the low-level open again. You can demonstrate this to yourself by comparing the times for the two code snippets below: