As a department, we've standardized on opening tables in the load event of
our forms. The only reason I can tell why this is, is for consistency's
sake. The code to open tables is always in the same place, regardless if it
is a form or a class. It also reduces the amount of rework that becomes
necessary when a form does become a class.

Only problem is, opening tables outside of a dataenvironment can take twice
as long as opening them in code.

I've done some testing on an empty form (no controls) with data opened from
the load and from the dataenvironment. There are 9 tables/views with
buffering, relationships and filtering set.

Here are the results.

==============================
4/28/0 11:45AM - TEST, COMPARISON BETWEEN OPENING TABLES IN
LOAD EVENT OR DATA ENVIRONMENT.
USING PRIVATE DATASESSION AND EMPTY FORM.

10 Hits 1st 1.604107 Avg 1.625375 X = g_oApp.m_append("frmUSERSTEST
DATAENVIRONMENT.SCX","",1)
10 Hits 1st 3.898160 Avg 3.165943 X = g_oApp.m_append("frmUSERSTEST
LOAD.SCX","",1)

USING DEFAULT DATASESSION.

10 Hits 1st 1.474473 Avg 1.594768 X = g_oApp.m_append("frmUSERSTEST
DATAENVIRONMENT.SCX","",1)
10 Hits 1st 3.446895 Avg 2.246119 X = g_oApp.m_append("frmUSERSTEST
LOAD.SCX","",1)
==============================

It not only shows that using the dataenvironment is up to twice as fast as
opening tables in code, it removes the performance hit that you tend to see
using private datasessions. This is great news and reflects the results
indicated in the "Using the Data Environment" blurb in the VFP programmers
guide, chapter 15 - Optimizing Applications.

--
William Fields
MCP - Microsoft Visual FoxPro
US Bankruptcy Court
Phoenix, AZ


"William Fields" <Bill_Fields@azb.uscourts.gov> wrote in message
news:3908a959$1@news.devx.com...
> I am beginning to love the coverage profiler....
>
> It doesn't seem to be the size of the table, small and large tables alike
> take just about the same amount of time to open.
>
> I don't know if you've seen the messages I've posted about the performance
> gains regarding our new server and VSS, but I've seen the same performance
> gains in our app on the new server. Unfortunately, not all of our clients
> have a new server and network infrastructure to run our app on.
>
> I've been doing further testing and even though the times reported back
from
> the coverage profiler are relative (not absolute), on my test form, it
shows
> that opening the tables/views takes up over 38% of my form's entire load
> time. The total form load time according to the profiler is just over 5
> seconds. While everyone says that VFP is blazingly fast at local table
> access, I'm starting to think that a true client/server solution may have
> some benefits regarding this opening of tables issue.
>
> --
> William Fields
> MCP - Microsoft Visual FoxPro
> US Bankruptcy Court
> Phoenix, AZ
>
>
> "Stephen Russell" <srussel3@midsouth.rr.com> wrote in message
> news:3908956b$1@news.devx.com...
> > My last app had a mill+ row table. It was used in a paramterized view
> and
> > was aways snappy.
> >
> > Environment was NT4 server (P200 64 meg 100mb backbone) to a P200
desktop
> > similar configuration.
> >
> > Master2 was a wide table (200 characters) and was an ANTI NORMAL table.
> But
> > it contained everything between 2 sides of the house in a SO - MFG
> > environment.
> >
> > Granted when I used a view off that table I would get 1 to 1500
> transactions
> > tops. The only hard part was updating the table every morning using an
> > update command.
> >
> > This same table would track all phases of Sales order, manufacture,
> > shipping, and freight claims.
> >
> > __Stephen
> >
> > "William Fields" <Bill_Fields@azb.uscourts.gov> wrote in message
> > news:390868d7@news.devx.com...
> > > You know, we thought about that, but views (even parameterized ones)
> open
> > up
> > > their base tables implicitly, so you're not only opening up the view
but
> > > also the tables the view is based on. From the command line, if you
open
> a
> > > view, you'll notice that all the tables the view uses also open. Am I
> > > thinking the right way here?
> > >
> > > --
> > > William Fields
> > > MCP - Microsoft Visual FoxPro
> > > US Bankruptcy Court
> > > Phoenix, AZ
> > >
> > >
> > > "Stephen Russell" <srussel3@midsouth.rr.com> wrote in message
> > > news:39085f78$1@news.devx.com...
> > > > Start tho think in C/S terms. Only views and only data that is
> > necessary.
> > > > outside of lookups never drag an entire tabel through the wire
unless
> > it's
> > > > report time.
> > > >
> > > > Get parmaeterized views for all you primary work tables.
> > > >
> > > > use my_dbc!lv_my_view nodata
> > > > set your lv_param
> > > > requery()
> > > >
> > > > __Stephen
> > > >
> > > >
> > > > "William Fields" <Bill_Fields@azb.uscourts.gov> wrote in message
> > > > news:390763c7$1@news.devx.com...
> > > > > We're trying to eek every bit of performance out of our
application
> > and
> > > we
> > > > > seem to always come back to the fact that loading tables over the
> > > network
> > > > > takes forever (even on our new fast server).
> > > > >
> > > > > Here's our situation...
> > > > >
> > > > > 1. At application startup, we open all the tables in our DBC in
the
> > > > default
> > > > > data session while showing a progressbar. This is not the problem,
> > users
> > > > are
> > > > > accustomed to waiting for applications to start while looking at a
> > > > > progressbar.
> > > > >
> > > > > 2. All our forms use private datasessions, and for the most part
we
> > want
> > > > > this. But is seems that private datasessions are a double-edged
> sword,
> > > > even
> > > > > though all our tables are open in the default datasession, the USE
> > > > > statements in the form load event take on average .5 seconds per
hit
> > > > > according to the coverage profiler. Most of our forms load between
> ten
> > > and
> > > > > twenty tables, so as you can see we're taking a pretty big hit.
This
> > is
> > > > our
> > > > > biggest problem.
> > > > >
> > > > > We have the ability to set our application logic to not allow
forms
> > from
> > > > > being active at the same time to prevent them from interfering
with
> > each
> > > > > other and then open them in the default datasession, but it would
be
> a
> > > > > tradeoff for the users who like to open multiple forms
> simultaneously.
> > > We
> > > > > could also denormalize our data, which may be the answer - most of
> the
> > > > > tables we open are used to populate comboboxes that are bound to a
> > > foreign
> > > > > key field in our main table. Maybe a normalized design is working
> > > against
> > > > > us?
> > > > >
> > > > > One approach that I've seen is to limit the amount of data that is
> > > > displayed
> > > > > on the form and to not open as many tables. When a user wants more
> > > > > information related to the current record, force them to open
> another
> > > > form.
> > > > > This approach distributes the performance issue, but forces the
user
> > to
> > > do
> > > > > more to get at the data they want to see in the first place.
> > > > >
> > > > > Any thoughts on the subject would be appreciated.
> > > > >
> > > > > --
> > > > > William Fields
> > > > > MCP - Microsoft Visual FoxPro
> > > > > US Bankruptcy Court
> > > > > Phoenix, AZ
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>