>I would also take into consideration that added labor of maintaining n duplicate definiions of your views- one for each workstation. It was proposed by Drew Speedie at DevCon that your framework use a programmatic DBC definition that is stored on the server, and when the workstations start the app, they grab that definition and run it, creating the dbc from scratch every time the app starts. This all sounds great in theory, but I know from experience that creating views from programmatic definitions along wit all the properties that must be set to make the view updatable takes a significant enough chunk of time to make it impractical for any of my apps to use this routine: startup would take 10 minutes.


use data\my_local.dbc exclu
zap
append from \\the_server\app_dir\data\applications.dbc

use

This is much faster than population the dbc with dbsetprop()'s

But why not just use \\the_server\app_dir\data\applications.dbc anyway? I don't see the enhancement for keeping it {dbc} local? That speed as compared to opening the tables and executing any / every view based sql? The worst performance is opening the tables. IMHO

My current system has only 10 tables inthe dbc and over 200 views. Most of the data that the views use are found in free tables still in a 2.6 environment. That .dct is just over 1.3 meg after I just packed it.

The speed issue here is proper indexing of source tables, reuse of deleted records, proper joining syntax.