connecting split database - paths 1

[dongle]

I have split a datbase which works fine on a standalone desktop.
When I transfer this to a machine on server the whole thing slows down and makes it almost unusable.
On looking at the paths which link the front end to the back end they go through the whole route including the server and network.
It is a slow network.

I would like to work as fast as it does on a standalone.

What is the best solution?

 

[lupins46]

>It is a slow network.
>I would like to work as fast as it does on a standalone.

It never will - even on a fast network - local access will always be faster.

There are actions you can take to help operational speed but if you have a slow network then it would be speculation as to whether they will produce accepatble performance.

There is a performance FAQ here:

http://www.granite.ab.ca/access/performancefaq.htm

 

[dongle]

Thanks for this Lupins46.

I think I will install it locally and then find a method to back up whole thing onto the server at the end of every session. It isn't too big as yet and it isn't requiered all the time.

What do you think?

 

[Hap007]

Dear Dongle,

With the cost of hardware so cheap these days, there is almost no reason to have a 'Slow' Network.

If you are running on a wireless network or over a long distance WAN, such as the internet, might be the only exception. In these cases, if you moved to SQL, you could improve performance.

Some suggestions network wise.
1) Make sure everyone has 100 meg nic network cards. They only cost about 30 bucks these days.
2) Make sure wiring is good, Cat 5
3) You could place the file (db, backend) on a Local PC and share the file and directory from the local PC.
4) You Should place the program (Frontend) on each users own Local PC.

Some suggestions Software wise.
1) If you open a form, say a customer update form, do not load all the records. Instead, do a primary lookup first, say ask for all customers whose last name begins with 'A or B or C etc...'. Then, in a query, read only those records qualify.
2) Only load data into subforms, when the subform in needed. So if a subform is on a tab control, and the tab page is not visible, disable the control until the user picks that tab.
3) Build your queries, using test data on a network, so you can identify performance problems while you are developing. Then you can try to fix at that time.
4) If you use selection criteria, do it on the first table in the sequence, thus reducing the overall data processed.
5) Make sure that queries are linked on Key fields only.

Hope This Helps,
Hap...

Access Developer

http://www.fcs-software.com/fcsaccessdev.html

Access based Add-on Solutions
Access Consultants forum

http://www.tek-tips.com/groups/accessDevelopers

 

[dongle]

This is very helpful and give me lots of ideas. Unfortunately the network is out of my control being a large local authority network. The network administrator states that it is slow - I can't see any major improvements taking place soon.