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 gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Set RecordSource Through VB vs Through a Query 3
- Thread starter mkallover
- Start date
-
1
- #2
Query optimization. A stored query taking advantage of Rushmore will probably load faster. You will see it mentioned here:
-
1
- #3
mkallover - you could always test it and draw your own conclusions.
From the reference of MajP - Make it look fast. (Guess that's why I drive a Porsche.)
I get a kick out of people who ask questions about speeding up their application. Even a cheap computer runs at 3,000,000,000 instructions per second. A person types at 10 characters per second. Throw in 1G Ram and hold on. Would someone really sense the difference in waiting a tenth of a second verus 2 tenths of a second? It's like nobody was around pre 1990.
Unions may have a point - if I produce more work in less time, do I get more pay? If not, then what's the rush?
From the reference of MajP - Make it look fast. (Guess that's why I drive a Porsche.)
I get a kick out of people who ask questions about speeding up their application. Even a cheap computer runs at 3,000,000,000 instructions per second. A person types at 10 characters per second. Throw in 1G Ram and hold on. Would someone really sense the difference in waiting a tenth of a second verus 2 tenths of a second? It's like nobody was around pre 1990.
Unions may have a point - if I produce more work in less time, do I get more pay? If not, then what's the rush?
-
1
- #4
TheAceMan1
Programmer
How are ya mkallover . . .
Except [blue]for large recordsets where query is always better[/blue], you'll have to decide by testing.
Note: [blue]the best Db's I've run across weren't necessarily fast, they were very efficient! . . .[/blue]
. . . and I agree with [blue]fneily[/blue]: [purple]just how good is speed that will never be preceived![/purple]
See Ya! . . . . . .
Be sure to see thread181-473997
Also faq181-2886
Except [blue]for large recordsets where query is always better[/blue], you'll have to decide by testing.
Note: [blue]the best Db's I've run across weren't necessarily fast, they were very efficient! . . .[/blue]
. . . and I agree with [blue]fneily[/blue]: [purple]just how good is speed that will never be preceived![/purple]
Be sure to see thread181-473997
Also faq181-2886
Gents, I have to disagree. I do not make this stuff up, in certain cases it is going to be more than noticeable not just a few milliseconds.
1. I have seen this in practice
2. The linked document from a fairly reilable source has seen the same:
"We've seen situations where a saved query loads significantly faster than the same SQL string stored as the RecordSource of a form. Somehow, saved queries are optimized more than the SQL string behind the report"
3. Litwin and Getz point this out as a good practice in their Desktop Developer books which I find to be one of the best Access sources out there.
I am kind of suprised by this quote,
If this was the case then no one should have forms that are a dog to load, but everyday some one posts on Tek-Tips that it takes forever for their forms/reports to load.
Sure this is only one tip in a quiver of performance increases, it is still something to understand and keep in mind. It might not be in the top ten, but, I would not dismiss it so fast.
1. I have seen this in practice
2. The linked document from a fairly reilable source has seen the same:
"We've seen situations where a saved query loads significantly faster than the same SQL string stored as the RecordSource of a form. Somehow, saved queries are optimized more than the SQL string behind the report"
3. Litwin and Getz point this out as a good practice in their Desktop Developer books which I find to be one of the best Access sources out there.
I am kind of suprised by this quote,
If this was the case then no one should have forms that are a dog to load, but everyday some one posts on Tek-Tips that it takes forever for their forms/reports to load.
Sure this is only one tip in a quiver of performance increases, it is still something to understand and keep in mind. It might not be in the top ten, but, I would not dismiss it so fast.
- Thread starter
- #6
fneily: I always thought people drove Porsches to make up for "shortcomings" elsewhere...
I wasn't necessarily asking from just a speed standpoint but for other possible drawbacks as well. What those might be I don't know but I was just curious.
Thanks for the input all.
I wasn't necessarily asking from just a speed standpoint but for other possible drawbacks as well. What those might be I don't know but I was just curious.
Thanks for the input all.
everyday some one posts on Tek-Tips that it takes forever for their forms/reports to load." Yeah, I agree. And what was the configuration of their computer? Hmmm, don't know.
We could also talk about efficient coding. OOP kinda killed that. If someone wants to increase performance, feel free. I just find it amusing. No judgement value on anyone. Geez.
I guess it's just bad of me to remember such things as 300 baud modems. Or dial phones. Or manual typewriters. How did humankind survive? Where I'm from, we originated, make the best, eat steam crabs. You must allocate at least 3 hours minimum for a meal. Sounds like someone would never make it.
We could also talk about efficient coding. OOP kinda killed that. If someone wants to increase performance, feel free. I just find it amusing. No judgement value on anyone. Geez.
I guess it's just bad of me to remember such things as 300 baud modems. Or dial phones. Or manual typewriters. How did humankind survive? Where I'm from, we originated, make the best, eat steam crabs. You must allocate at least 3 hours minimum for a meal. Sounds like someone would never make it.
TheAceMan1
Programmer
Howdy MajP . . .
I have a benchmark for a routine that took 46 milliseconds with VBA (just a loop) and 2 milliseconds thru query! Although 23 to 1 is a nice ratio and reduction in time, I doubt anyone would preceive the change. However, programming for speed should be done (preceived or not), particularly if recordcounts are expected to get large.
See Ya! . . . . . .
Be sure to see thread181-473997
Also faq181-2886
I couldn't agree with you more. I was just stipulating time changes that can't be preceived.MajP said:
I have a benchmark for a routine that took 46 milliseconds with VBA (just a loop) and 2 milliseconds thru query! Although 23 to 1 is a nice ratio and reduction in time, I doubt anyone would preceive the change. However, programming for speed should be done (preceived or not), particularly if recordcounts are expected to get large.
Be sure to see thread181-473997
Also faq181-2886
- Status
Similar threads
