By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
462,232 Members | 425 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 462,232 IT Pros & Developers. It's quick & easy.

Form slows down (calculating) when Idle

100+
P: 547
I have this strange situation. When capturing data, the capture form seems to "slow down to a stand still" almost, should one stop capturing for a few minutes. I then close the application and everything is back to normal, unless the data capturer takes a break. Is this a Windows 7 related issue, or Access taking a "power nap"?
Any Suggestions about his strange behavior when it shows calculating at the bottom of the screen?
Feb 26 '14 #1
Share this Question
Share on Google+
6 Replies

zmbd
Expert Mod 5K+
P: 5,397
What does the code say?
Feb 27 '14 #2

100+
P: 547
ZMBD, its a form with various dlookups and a subform. I just want to inquire if its a common problem on a busy form/subform with a table of about 200 000 row. The subform does not show the records on opening.

I have an idea that the 4 dlookups calculating stocklevels in the background using queries, after adding an item to the subform,are the cause. Would it help to disable these dlookups after completing a record and the enabling them when adding a new one?
The only "error" is is it shows is "calculating" at the botton of the screen.
Feb 27 '14 #3

zmbd
Expert Mod 5K+
P: 5,397
You're going to have to provide more detail...
How are the dlookups "running" in the background when there's no active code?
I have functions in unbound controls on subforms; however, these are only ran when they become visible and I've never had a slowdown that anyone has noticed. This however, may not be how you are "running" your dlookups and/or other code SQL... there maybe something that needs a doevents to allow the system to clear, or a ton of other issues... you've simply not supplied enough information to help.
Feb 27 '14 #4

NeoPa
Expert Mod 15k+
P: 31,770
It's really hardly possible to comment when most of the information about your actual problem is not shared, but only referred to obliquely.

Using Domain Aggregate functions (DLookup() etc) is generally likely to cause poor performance as every call requires a recordset to be initialised and executed. As we know so little in the way of details of what's actuially going on though, even that part is only guesswork.
Mar 1 '14 #5

100+
P: 547
Sorry have been away for a few days. I seem to have improved the speed issue drastically with the dlookups by using enabled=false on loading the form, then enabled=true in the click event of the first field in the subform row , and setting enabled= false in the last field of the row again for 6x dlookups.
Expand|Select|Wrap|Line Numbers
  1. [Forms]![orderf]![StockIn].Enabled = True
  2. [Forms]![orderf]![StockIn].Enabled = False
  3.  
Mar 4 '14 #6

zmbd
Expert Mod 5K+
P: 5,397
GUESSING HERE

You have the dlookup() in the "control source" property of a control within the details section of the form.

I F F this is the case, then what Neopa stated in his post is starting to catch up with you and a shortcut on the form.... now I do use this construct myself; however, only for a limited return of records, say a dozen or so at the most; however, for thousands, I would most likely not use this and try to find a better method for the reason Neopa states.
Mar 4 '14 #7

Post your reply

Sign in to post your reply or Sign up for a free account.