>>>Sorry, I do not use DEs any more, so haven't seen that problem. You can always open the tables in the Load, too, as I do, that will remove the problem.
>>
>>Bruce,
>>
>>For reasons of speed?
>>
>>Just curious as to why you arrived that that decision.
>
>Hi Doug - been away a few days - no, not for performance, I don't think that's an issue. Basically, to have more control over things. We have a very large app with dozens of DBCs and hundreds of tables in each one (several unique table types) that are identical in structure but have different names and paths. I use common ALIASes for all identical tables, but the easiest way to open them for dozens of forms is to do it manually once. Mainly, I do this in a top-level/entry-screen based on user access-level and selection, though a few are done in Loads of forms opened later, all based on top-level property path-strings created from user selections & access rights.
>
>DEs just didn't work well for this kind of app. And then once I built a "framework" method of manually opening tables, indexing views, setting different buffering levels, some tables opened EXCL, some aren't, etc, I just became accustomed to it, even in apps that aren't as complex...DEs were to confining for a lot of my tasks, I guess is the bottom line.
Bruce,
Thanks. I was just wondering what your thought process was. There was something of a brouaha here about frameworks, VB, middle-tier stuff and so forth and it was in that context I asked my question. Personally I think frameworks are perfectly aceptable if the nature of the desired application lends itself to the framework. *g* Apparently yours would be one such application, even to the point of needing to abandon the "new" FoxPro framework, the DE.
Best,
DD
Best,
DD
A man is no fool who gives up that which he cannot keep for that which he cannot lose.
Everything I don't understand must be easy!
The difficulty of any task is measured by the capacity of the agent performing the work.