query <> sql = velocity

[matrixknow]

I am wondering if a query is running faster or slower then the sql (the same as your sql of you query) in your code ?

 

[maxhugen]

When you run a saved query, Access tries to optimise the way it runs, and then saves this info with the saved query for the next time it runs.

Running the same query as an SQL string in code, such as when getting a recordset, won't be as fast as it hasn't been optimised by the JET engine.

However, in many cases you'll be hard pressed to notice any change in speed, given todays faster processors and vastly increased RAM.

Of course, you can save the query, and then use it as part of your SQL string in the code.

HTH



Max Hugen
Australia

 

[missinglinq]

Max raises a very good point! Back in the dark ages, when DOS ruled, "big" hard drives were 40 mb and "fast" CPUs clocked 33mhz, questions like this were serious stuff! Programmers vied to see who could accomplish a given task with the fewest lines of code (HDD space was at a premium) and who could do it the fastest! But today, with the aforementioned faster processors and vastly increased RAM, these type questions are essentially moot, especially when it comes to Access! Despite all the hoopla about multi-tasking, the vast majority of end users still do one thing at a time. Discussions about this procedure or that procedure chewing up processor time are really academic. I see questions every week about progress bars that don't work, and when you start investigating, you find out that the progress bar is working, it just appears and disappears faster than the human eye can register because the process it's tracking is done and over so quickly! When you start seeing processes in Access taking multiple minutes, you can pretty well be assured that something is seriously amiss!

The Missinglinq

Richmond, Virginia

There's ALWAYS more than one way to skin a cat!

 

[maxhugen]

G'day Missinglinq

When you start seeing processes in Access taking multiple minutes, you can pretty well be assured that something is seriously amiss!

Yeh, like when you find half your users in a major corporation are only barely out of those dark ages... still running PI processors with bugger-all RAM and viewing your beautiful app on 800x600 screens, over a network where data must surely be transported by camels!

Max Hugen
Australia

 

[matrixknow]

other things beside good PC are :
1. Network capacity.
2. Large Queries.
3. Amount of records.
4. Access is a desktop database, not comparable with Oracle or SQL SERVER. Performance problems are inherited.

 

[missinglinq]

Hey, Max! I almost added here (and on another post elsewhere today) that you have to understand, when writing apps for businesses you're not associated with, that many, many companies are still operating with antiquated hardware and/or software. People have no idea how many legacy systems are still out there running DOS based apps! The single biggest factor I see in companies finally moving to upgrade software is when their old printers go kaput and the new USB printers won't work with DOS!

The Missinglinq

Richmond, Virginia

There's ALWAYS more than one way to skin a cat!

 

[maxhugen]

Heh-heh, too right missinglinq!

Which is why I avoid domain functions (see

http://www.tek-tips.com/viewthread.cfm?qid=1381611)

if possible, especially when called for every row in a report.

I must have read every post in every forum re speeding up Access apps.

Max Hugen
Australia