SQL versus Queries

  • Thread starter Thread starter DS
  • Start date Start date
D

DS

Which is better to use? SQL or Queries? Is one faster than the other?
Is one more bullet-proof than another?
Thanks
DS
 
I believe they are simply different views of the same thing. You can open a
query in SQL view. You can use an SQL as the source for a form or report,
and invoke the query-builder on it.

Typically I try to imbed the query in the record source of my reports and
forms rather than using a saved query. I am not sure if it is any faster,
but it does keep my database window a bit cleaner. The only time I use a
saved query is if it can be used by multiple reports and I don't feel like
copying and pasting it.
 
Which is better to use? SQL or Queries? Is one faster than the other?
Is one more bullet-proof than another?
Thanks
DS
Click to expand...

Queries *ARE* SQL.

The query grid is simply a tool to build SQL for you. Every query
exists as a SQL string (and as a not-publicly-documented "compiled
query"); some queries such as UNION or PassThrough queries exist ONLY
as SQL.

You get a bit more flexibility by writing your queries directly in SQL
(parenthesized AND/OR logic for example), and such queries can in fact
be more efficient; but the query grid is still an excellent tool which
I use routinely.

John W. Vinson[MVP]
 
Rick said:
I believe they are simply different views of the same thing. You can open a
query in SQL view. You can use an SQL as the source for a form or report,
and invoke the query-builder on it.

Typically I try to imbed the query in the record source of my reports and
forms rather than using a saved query. I am not sure if it is any faster,
but it does keep my database window a bit cleaner. The only time I use a
saved query is if it can be used by multiple reports and I don't feel like
copying and pasting it.
Click to expand...
Thanks Rick. I appreciate the input.
DS
 
John said:
Queries *ARE* SQL.

The query grid is simply a tool to build SQL for you. Every query
exists as a SQL string (and as a not-publicly-documented "compiled
query"); some queries such as UNION or PassThrough queries exist ONLY
as SQL.

You get a bit more flexibility by writing your queries directly in SQL
(parenthesized AND/OR logic for example), and such queries can in fact
be more efficient; but the query grid is still an excellent tool which
I use routinely.

John W. Vinson[MVP]
Click to expand...
Very interesting. So the Query is kinda of a GUI to write SQL!
Thanks
DS
 
John,

I thought that the fact that saved queries are saved as "compiled"
query helps to make the query faster. If this is so, then the saved
query would infact be faster than using SQL (as form's recordsource,
combobox's, etc.).

And the query designer is just a GUI to write SQL. Any query you
create, you can click on View-SQL and see the sql used to create the
query. This is probably the best way to learn SQL.


Chris Nebinger
 
John,

I thought that the fact that saved queries are saved as "compiled"
query helps to make the query faster. If this is so, then the saved
query would infact be faster than using SQL (as form's recordsource,
combobox's, etc.).
Click to expand...

The SQL statements that are stored in form and report properties are
compiled just as saved queries are so the point is moot there. For dynamic
SQL that is generated in code yes there is a bit of a hit, but on modern PCs
this hit is so tiny as to be a non-issue as well.
 
Very interesting. So the Query is kinda
of a GUI to write SQL!
Click to expand...

Yes, when we adopted Access, we got a personal assitant to write Jet SQL for
us -- the Query Builder.
 
Back
Top