Reducing form load time...??

[William Fields]

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

[Stephen Russell]

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
>
>
>
>
>
>

[William Fields]

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
> >
> >
> >
> >
> >
> >
>
>

[C Qualset]

Microsoft says that loading is slowed by having data bound to controls at
load time. They suggest, and I am about to try, storing the controlsource
value in some other property (comment maybe) and populating the controlsource
on focus of the control.

In other words, in your control's onfocus method, you check for an empty
controlsource and a not empty 'comment' property and copy one to the other.
Seems this can be easily done in your control parent classes.

I'm interested to know results if you try this.

"William Fields" <Bill_Fields@azb.uscourts.gov> wrote:
>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
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>

[Stephen Russell]

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
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>

[William Fields]

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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

[William Fields]

This approach seems pretty foreign to me, has anyone else attempted this?


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


"C Qualset" <qualset@acm.org> wrote in message
news:39088bc3$1@news.devx.com...
>
> Microsoft says that loading is slowed by having data bound to controls at
> load time. They suggest, and I am about to try, storing the controlsource
> value in some other property (comment maybe) and populating the
controlsource
> on focus of the control.
>
> In other words, in your control's onfocus method, you check for an empty
> controlsource and a not empty 'comment' property and copy one to the
other.
> Seems this can be easily done in your control parent classes.
>
> I'm interested to know results if you try this.
>
> "William Fields" <Bill_Fields@azb.uscourts.gov> wrote:
> >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
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
>

[Fred Taylor]

Opening a table is one of the slowest things that you can do in Windows (not
just VFP). But VFP has an advantage that anything that is already open is
much faster to open again. Are ALL the tables that you see the slow Private
Datasession table opening already open in the Default Datasession? I've
never really measured how long it takes, but if a table is already open, it
opens much, much faster in the Private Datasession, then if the PD has to
open it for the first time.

Fred

PS:
Thanks Bill, for the info on the VSS HotFix. I had called M$ about that
before, but nobody had the slightest idea what I was talking about!


William Fields wrote in message <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
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>

[William Fields]

Yes, we cycle through our .dbc (using ADBOBJECTS()) when the app starts and
open every table in the default datasession.

I do know that opening tables up in private datasessions that are already
open in the default one is much much faster.

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


"Fred Taylor" <ftaylor@uswest.net> wrote in message
news:3908adf3@news.devx.com...
> Opening a table is one of the slowest things that you can do in Windows
(not
> just VFP). But VFP has an advantage that anything that is already open is
> much faster to open again. Are ALL the tables that you see the slow
Private
> Datasession table opening already open in the Default Datasession? I've
> never really measured how long it takes, but if a table is already open,
it
> opens much, much faster in the Private Datasession, then if the PD has to
> open it for the first time.
>
> Fred
>
> PS:
> Thanks Bill, for the info on the VSS HotFix. I had called M$ about that
> before, but nobody had the slightest idea what I was talking about!
>
>
> William Fields wrote in message <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
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >
> >
>
>