Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 189
  • Last Modified:

Speeding up calculations on the Main Menu

I have an Access database, that goes straight into a Main Menu when it is opened.  On the Main Menu there are buttons that display information such as how many call backs are outstanding, how many companies are in the database etc, etc.  In total there is room for up to 20 calculations.

Over the years, I have played about with various methods for calculating this information as quickly as possibe.  I used to simply use the Dcount function on the main table, but this was always slow - especially if several people were logging in at the same time.  I found that a quicker way was to create a make table query, that copied the main table to the local front-end (the back-end is on the server).  Although this works fine, the database gets bloated.  The local data is always removed upon exit and the front-end is compressed and re-compacted - but the downside of this is fragmentation will still occur on the hard drive.

After all that - my question is this.  Does anybody know of a faster way to make these calculations without the, "make table query" (the indexes are spot on, and transferring to SQL is not an option for this project)?

All the best and thanks for your help
0
Andy Brown
Asked:
Andy Brown
  • 3
  • 2
1 Solution
 
jerryb30Commented:
Are all of the calculations done on a single table?
Can you post sample of SQL you used for calculations?
0
 
Andy BrownAuthor Commented:
Thanks for your help.  

Yes - all from one table.

The make table query contains only the fields that I will perform calculations on.  Once created I will then run a Dcount on the specified criteria.  For example, I have a field called ActionDate, which is updated when a call back is logged by an operator.

Here is an example of the code I would use:

me.TBCallBacks = Dcount("*","tmpCalculations","ActionDate <= Date()")
0
 
stevbeCommented:
for the simplest of examples using a saved query with SQL of:
SELECT Count(*) AS MyCount FROM tblPO;

and then grabbing the value from a recordset of that query will be faster than a DCount (DCount has gotten faster over the years, especially if you use
DCount("*", "tblPO")

Me.txtCount = CurrentDB.OpenRecordset("qselCount").Collect(0)

0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
stevbeCommented:
a saved query will execute faster than any Dxxx function because it will be optimized by the query execution engine to take advantage of index.
0
 
Andy BrownAuthor Commented:
Hi,
That's quite interesting, the only issue is that the query may need to be changed by the users.  For example, they may decide that they wish to count all of the records with X in a field.  They are also all using MDE front-ends - could I still use this solution.  And finally, I have experienced issues in the past when two users log in at the same time and get a locked message.

0
 
stevbeCommented:
<the query may need to be changed by the users>
How do you get their criteria now? How many criteria sets can they enter at the same time?

You could change the line a little to open a snapshot recordset which *should* process slightly faster. Any time you are doing an aggregate SQL Access will toss a quick lock to make sure it can return accurate results but that should be really quick.

CurrentDB.OpenRecordset("qselCount", dbOpenSnapshot).Collect(0)




0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now