Connecting to different BE really slow on network

[Ron]

Hi All,

Access2000. WinXP, Win98, WinVista all work the same

I have a FE that connects to different BE's based on the user's
selection off a drop down menu. Upon starting the ap, the user
decides what "office" they want to work with, select it off the list,
and all the appropriate tables (50) in the BE are then linked into the
ap.

On the computer where both the FE and BE are located, this un-linking/
re-linking happens instantaneously. So quickly you can hardly see the
unlinking and relinking screens I display to let the user know the
program is working.

On all other users over a network, this process takes at least 1
second, sometimes longer, per table. Under my developement system, I
open the tables window first so I can watch the tables window become
blank because of the deleteobject commands, but this happens pretty
fast, and then repopulate with the transferdatabase command. V-E-R-Y
s-l-o-w-l-y. Like I say, at LEAST 1 second, sometimes 2, per table.

So, by the time all 50 tables are linked, there's been at LEAST a
minute lag time, sometimes more. Why would a network user be so much
slower than the user with both FE and BE? And, is there some way
around that time lag? Possibly I need to ask this in a networking ng,
but thought I'd start here.

TIA,
ron

 

[Arvin Meyer [MVP]]

Are the slow users running the front-end on their own workstation, or are
the running it from a server on the LAN?

Why are users working directly on the server? Is it really a server, or a
workstation designated as a server?

 

[Ron]

Hi Arvin,

Everyone has their FE on their own workstation.

Workstation designated as "server". Business owner too cheap to dedicate a
machine as server and not use. It's a P2P network so lots of sharing going
on.

I have tried to have no one working on server for a day or 2 and no
difference in speed loading these files is noticable.

 

[Arvin Meyer [MVP]]

Workstations don't make very good servers. I'd try moving everything to
another machine to act as a server, and see if that improves just that
workstation, or all workstation. Use the machine with the fastest processor,
and the most RAM as the server.

With some servers selling below $1000 now, it doesn't pay to be penny-wise
and pound foolish.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

 

[Albert D. Kallal]

After you link the first table...open it.....

The rest of the re-link process will occur at full speed.....

 

[Paul Shapiro]

I usually open that first table with sql that minimizes the data being held:
Select Top 1 * From TableName
or
Select * From TableName Where 1=0

 

[David W. Fenton]

m:

I have a FE that connects to different BE's based on the user's
selection off a drop down menu. Upon starting the ap, the user
decides what "office" they want to work with, select it off the
list, and all the appropriate tables (50) in the BE are then
linked into the ap.

I would never implement separate back ends for different offices.
Instead, I'd put everything in one back end and tag the appropriate
records in one of the tables as belonging to a particular office.
With that, the choice from the dropdown list would do nothing but
filter the data.

Any app that has to relink repeatedly is wrongly designed, in my
opinion.

 

[Ron]

Hi David,

Since you have no idea of what has been required, both business wise, and
legality wise, your "opinion" is not worth the bits and bytes it takes to
display it.

The "owner" of each database is the office involved, contractually. To mix
the data of even 2 offices (and there are 8 I think at present with more to
add in the near future) would not only be against these contractual
requirements (that existed long before I came on the scene) but would also
be impractical on a future needs basis for other valid reasons.

I realize it would have been easier to design the whole shabang another way
and in the beginning this was explained to the powers that be. The
individual owners of the data files wanted it this way and this is the way
they got it.

If you'd "never" do it this way, then you would never have been in a
position to do this work. I DID get the work because I was flexible enough
to work around the business limitations that have existed since the early
'80s (rightly or wrongly).

Again, David, if you have input on my original question that will help solve
my problem, I'm all ears (eyes?). Otherwise, kindly keep your uninformed
opinions to yourself, please.

Thanks,
ron