Link to home
Start Free TrialLog in
Avatar of fb1990
fb1990

asked on

Help calculating differences in values based on Date in Access Upd

Hello EE,

I raised a question on how to calculate the difference in values based on Date in Access.  Please refer to the posting here - https://www.experts-exchange.com/questions/28371877/Help-calculating-differences-in-values-based-on-Date-in-Access.html I received an answer that worked but when applied to about 50,000 records, the query was extremely slow.  Can someone please help examine the code and help streamline the process?  My data is attached to this question - https://www.experts-exchange.com/questions/28371877/Help-calculating-differences-in-values-based-on-Date-in-Access.html

Thanks in advance for your help
Avatar of PatHartman
PatHartman
Flag of United States of America image

Correlated subqueries tend to be slow.  If you can do this calculation in a report it will be significantly faster because you won't need to run a sub query for EVERY row of the main query.  Instead you just refer back to the previous row.

Additionally, try adding a non-unique index on the date field.  That will help the subquery get to the correct record.
Avatar of fb1990
fb1990

ASKER

Thanks Pat as always.  Can show me by way of example how your suggestion can be implemented?
ASKER CERTIFIED SOLUTION
Avatar of Gustav Brock
Gustav Brock
Flag of Denmark image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Start by adding an index to the date field to see if that helps.  If it doesn't, remove the index.  No sense having it if it isn't going to help.

To calculate in a report, create two global variables.  Use the Print event to save the current "ID" and value.  Use the Format event to compare to the ID saved by the Print event and calculate the difference.

The thing you need to worry about in a report when you are doing this type of processing is that the Format event might run more than once (if the current record won't fit on the page, Access has to back up and print the page headers, etc and then reprint the detail line) and so can double up on calculations.  Saving the "current" values in Print should eliminate this problem as long as you don't have any running totals.   The Print event has a PrintCount argument so you can always tell that the event has run before if you need to know that.  The Repeat event only runs when Access determines that it can't print the current record because it won't fit on the page.  If you were doing running sums, you would use this event to back out the amounts for the current record so they can be added again in the Format event.
Avatar of fb1990

ASKER

Pat, Thanks for the suggestions.
Avatar of fb1990

ASKER

Thank you so much or should i say Tak så meget.  The solution produced my result in a mini fraction of my original process
You are welcome!

/gustav