When loading the Access97 form, it is very slow to open. Two factors (I think) that might be slowing it down. First, both separate .mdb files for data tables and the other for the form are located in the network drive. Second, I have multiple combo lists in the form. I have tested both files in my local drive, and it works great. However, these files need to be in our network drive due to multiple end-users accessing the form for data entry. Please advice.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Very slow response when form is loading. 2
- Thread starter scra
- Start date
I have found this on occassions and can only suggest the following which may or may not apply in your case.
1) Check that you don't have obsolete code hanging around in the form module, sometimes old bits tend to make it 'hang about'
2) Check the indexing on your tables, large tables will take longer to load if indexing is inefficient.
3) Compress your data tables, again after doing lots of work on appending/deleting etc I find that the tables db needs to be compressed to speed it up.
These checks ususally help for me.
1) Check that you don't have obsolete code hanging around in the form module, sometimes old bits tend to make it 'hang about'
2) Check the indexing on your tables, large tables will take longer to load if indexing is inefficient.
3) Compress your data tables, again after doing lots of work on appending/deleting etc I find that the tables db needs to be compressed to speed it up.
These checks ususally help for me.
Junior1544
Technical User
In addition to the last post's great suggestions, I tend to stay away from combo box's that i base on another table or query... I do this because then the database needs to transfer more tables across the network,... Just another idea for you...
--James
junior1544@jmjpc.net
Life is change. To deny change is to deny life.
--James
junior1544@jmjpc.net
Life is change. To deny change is to deny life.
-
1
- #4
gusbrunston
Programmer
Hi:
The most effective thing I have ever done to speed up the loading of forms I got from the following thread:
Bry12345 (Programmer) May 15, 2002
Check your settings under Tools, Options, General and make sure that 'Perform Name Autocorrect' is not selected.
This function scans the Db and looks for errors caused by renaming objects. When enabled, it has been known to slow down the performance of split db's on a network.
Other than that, it helps if the workstations are PIV's with 256mb ram.
Hope this helps, Gus Brunston![[glasses]](/data/assets/smilies/glasses.gif "[glasses] [glasses]")
An old PICKer, using Access2000. I manage Suggestions welcome. padregus@attbi.com
The most effective thing I have ever done to speed up the loading of forms I got from the following thread:
Bry12345 (Programmer) May 15, 2002
Check your settings under Tools, Options, General and make sure that 'Perform Name Autocorrect' is not selected.
This function scans the Db and looks for errors caused by renaming objects. When enabled, it has been known to slow down the performance of split db's on a network.
Other than that, it helps if the workstations are PIV's with 256mb ram.
Hope this helps, Gus Brunston
An old PICKer, using Access2000. I manage Suggestions welcome. padregus@attbi.com-
1
- #5
Possible ways to improve performance...
- Run a copy of your front-end on the local desktops rather than on the server (a Must). This is the copy that is linked to your back-end tables located on the server.
- If you don't mind the wait, set the Rowsource of the combo boxes on a on-demand basis rather than loading with the form. This can be implemented a couple of ways.
- If possible, limit the size of your initial recordset through a filtering form that allows a user to pre-select certain load options. Say, load records pertaining to a particular state or something.
- Perhaps you can generate the illusion of a fast loading form by opening the form as a hidden object. After the background records are loaded, make the form visible to the user. But, in the meantime, just display an hourglass.
Just a thought.
Gary
gwinn7
A+, Network+
- Run a copy of your front-end on the local desktops rather than on the server (a Must). This is the copy that is linked to your back-end tables located on the server.
- If you don't mind the wait, set the Rowsource of the combo boxes on a on-demand basis rather than loading with the form. This can be implemented a couple of ways.
- If possible, limit the size of your initial recordset through a filtering form that allows a user to pre-select certain load options. Say, load records pertaining to a particular state or something.
- Perhaps you can generate the illusion of a fast loading form by opening the form as a hidden object. After the background records are loaded, make the form visible to the user. But, in the meantime, just display an hourglass.
Just a thought.
Gary
gwinn7
A+, Network+
- Thread starter
- #6
Well, first create the form that will serve as your progress indicator (seen below as "ProgressMessage"
. Next, when you open your primary form, the following code runs...
DoCmd.OpenForm "ProgressMessage"
DoEvents
DoCmd.OpenForm "MyMainForm", , , stLinkCriteria, , acHidden
DoCmd.Close acForm, "ProgressMessage"
Forms(stDocName).visible = True
Gary
gwinn7
A+, Network+
. Next, when you open your primary form, the following code runs...DoCmd.OpenForm "ProgressMessage"
DoEvents
DoCmd.OpenForm "MyMainForm", , , stLinkCriteria, , acHidden
DoCmd.Close acForm, "ProgressMessage"
Forms(stDocName).visible = True
Gary
gwinn7
A+, Network+
- Status
Similar threads
