Access database too slow from a laptop 1

[snowyowl]

Has anybody had problems with the speed of their database from using it on a laptop. I have written a form based database and it has just started to be tested on a remote laptop using a 56k modem and VPN link to our server at head office. The response times are very slow (from a couple of minutes per mouse click) and sometimes the link stops responding altogether.

Is there any way I can get the response times quicker. I've tried making the database as small as possible and I have never developed in data access pages before. Is this going to be the way to do it. The database is quite complex with at least 16 tables with plenty of one to many relationships set up.

 

[Ecniv]

Bound forms??


Try unbound, as you only need to get information on the clicks, possibly use a list as a display so users can see the data before clicking??

56k connection is the problem But have a go at the above (possibly?).


Vince

 

[psemianonymous]

I'm in agreement with the above--be very careful how much data you're pulling from the database. Watch out for comboboxes/listboxes that pull information from a table, as well as the forms themselves.

If you haven't done so already, split the database and put the front-end on the laptop.

Also, for ADP-specific question, check out the Access: DAP/ADP forum for what is very likely better advice than I can give.

--
Find common answers using Google Groups:

http://groups.google.com/groups?group=comp.databases.ms-access

Corrupt MDBs FAQ

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

 

[perrymans]

Can you guys expound on you unbound form suggestion? I don't think I follow what you mean, but I am always looking for speeding things up. I have so far only ever used unbound forms for calculations and the like, but I always have bound controls. I thought that was how it was supposed to be done.

So I assume you use unbound controls and when they click save or next, then the form is linked to a table and saved? Does this only apply to data entry? How could this be possible on a form showing numerous records?

Thanks> Sean.

 

[psemianonymous]

Bound forms do a lot of work for you, thus you use them.


If, however, you're getting unusable speeds over the VPN connection/56k modem, then I recommend you switch your form from bound to unbound. This means that you take out all the stuff Access does for you, and replace it with code that does it manually--and hopefully using less bandwith in the process.

This means that yes, you will have to use a recordset and manually fill in the data in each control, and to save you will have to either run an SQL UPDATE statement or update the recordset. It's more work, but it will hopefully speed up load times from several minutes to ... well, I don't know the specifics of your situation, but let's say "less than a minute" to be safe.

You're asking about specifics for unbound forms--and yes, you will lose the ability to do a 'continuous form' if you switch to unbound. You will lose some features that are already programmed in, but this is necessary for compatibility with awful VPN connections. You have an extremely narrow pipe, and Access was not designed for such limited bandwith. Switching to unbound forms is one step.


Splitting your database is a better step, and you still haven't replied about that. Believe me, it is absolutely necessary in this case.



Another option from all this mess is to use Terminal Server to connect to your database. This way your database may run normally even for users with a narrow pipe.

--
Find common answers using Google Groups:

http://groups.google.com/groups?group=comp.databases.ms-access

Corrupt MDBs FAQ

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

 

[snowyowl]

Thank you for these suggestions on how to get over the response times problem. I will try splitting the database as suggested and see if this will speed up the adsl link.

How would I find unwanted VB code that may be hanging around in the database and does this make any difference to performance ?

Is there anything else I should look for to delete to make the database smaller?

Any suggestions would be appreciated or I may have to convert to data access pages