FMPRO 9 Open Remote initial access Screen Refresh?

Greetings,

We have a remote offce that hosts our FMPRO 9 DB. We open the 'remote' via
specifying the IP address using a VPN connection. Things work well.
However, the initial screen refresh paints a bit slow the 1st time we access
a particular view. Any further work in the current view is speedy. If we
close the DB and open it again- the process repeats. Is this a cached
process that can be improved, or pre-cached?

Any tips are appreciated.
Thanks in advance.

Re: FMPRO 9 Open Remote initial access Screen Refresh?

On 2007-10-19 19:45:59 -0700, "Wad4iPod" said:

> We have a remote offce that hosts our FMPRO 9 DB. We open the 'remote' via
> specifying the IP address using a VPN connection. Things work well.
> However, the initial screen refresh paints a bit slow the 1st time we access
> a particular view. Any further work in the current view is speedy. If we
> close the DB and open it again- the process repeats. Is this a cached
> process that can be improved, or pre-cached?

Unfortunately, the initial screen draw is always going to download the
screen elements and the records IDs the first time you view each screen.

Some developers use local interface files to contain all the buttons
and graphics, but this causes difficulty when upgrades come along.
There can also be problems with file references in this arrangement.

Some optimization tips could help the speed of initial draw:

1. Use only FM native elements on screen. Eliminate jpgs, pngs or tiffs
used on screen. Restrict the numbers of elements if possible. Move
more navigation and operation into menus rather than buttons. Use text
blocks instead of drawn buttons.
2. Restrict the found sets that the user views initally. If you can
display 25 records instead of 2500, the download will be faster.
3. Use list views instead of portals where possible. Use unsorted
portals instead of sorted portals where possible.
4. Do not display summary fields on normal viewing or navigating screens.
5. Use auto-enter calcs or number fields set by script rather than
unstored calc fields that depend on related table data.

All these things will help performance in general and remote
performance specifically.
--
Lynn Allen
--
www.semiotics.com
Member Filemaker Business Alliance
Long Beach, CA

Re: FMPRO 9 Open Remote initial access Screen Refresh?

Thank you Lynn. Much appreciate your time..


"Lynn Allen" wrote in message
news:4719941b@news.bnb-lp.com...
> On 2007-10-19 19:45:59 -0700, "Wad4iPod" said:
>
>> We have a remote offce that hosts our FMPRO 9 DB. We open the 'remote'
>> via
>> specifying the IP address using a VPN connection. Things work well.
>> However, the initial screen refresh paints a bit slow the 1st time we
>> access
>> a particular view. Any further work in the current view is speedy. If
>> we
>> close the DB and open it again- the process repeats. Is this a cached
>> process that can be improved, or pre-cached?
>
> Unfortunately, the initial screen draw is always going to download the
> screen elements and the records IDs the first time you view each screen.
>
> Some developers use local interface files to contain all the buttons and
> graphics, but this causes difficulty when upgrades come along. There can
> also be problems with file references in this arrangement.
>
> Some optimization tips could help the speed of initial draw:
>
> 1. Use only FM native elements on screen. Eliminate jpgs, pngs or tiffs
> used on screen. Restrict the numbers of elements if possible. Move more
> navigation and operation into menus rather than buttons. Use text blocks
> instead of drawn buttons.
> 2. Restrict the found sets that the user views initally. If you can
> display 25 records instead of 2500, the download will be faster.
> 3. Use list views instead of portals where possible. Use unsorted portals
> instead of sorted portals where possible.
> 4. Do not display summary fields on normal viewing or navigating screens.
> 5. Use auto-enter calcs or number fields set by script rather than
> unstored calc fields that depend on related table data.
>
> All these things will help performance in general and remote performance
> specifically.
> --
> Lynn Allen
> --
> www.semiotics.com
> Member Filemaker Business Alliance
> Long Beach, CA
>