Re: Speed Effeciency on Form updates
- From: "Allen Browne" <AllenBrowne@xxxxxxxxxxxxxx>
- Date: Sun, 15 Feb 2009 20:34:29 +0900
The answer depends on what the calculations are, and how many disk reads, recordset opens etc are involved in them.
In general, it's best to do anything that SQL can do first, such as joins, aggregation, criteria, subqueries, queries stacked on each other.
Once you hit a wall with SQL, you can start thinking about a VBA solution.
If that gets too inefficient also, you will need to consider using a temporary table to store the partially massaged data for further processing.
--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"KM" <KM@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:2739844D-B29A-479C-AFEA-C19FAD65745F@xxxxxxxxxxxxxxxx
Question on overall Form design
Have a lot of data on a financial form, 20 rows, 8+ columns
In addition, delta columns are present and math on these can change
depending on the user choices.
Question:
Is it more effecient to us VB to calculate column differences and stuff the
results into the form fields or is it better to use controlsource property
and set the formula within the field and let the form calculate it?
.
- References:
- Speed Effeciency on Form updates
- From: KM
- Speed Effeciency on Form updates
- Prev by Date: RE: Access 2007 file crashes when opening forms or tables
- Next by Date: Re: Speed Effeciency on Form updates
- Previous by thread: Speed Effeciency on Form updates
- Next by thread: Re: Speed Effeciency on Form updates
- Index(es):
Relevant Pages
|
