Query builder

  • Thread starter Thread starter laura
  • Start date Start date
L

laura

I'm still very much at the learning stages. A lot of my programs rely on the
Query Builder - it's quick and easy to understand and implement. However, I
am finding that the list of queries grows and grows and that in itself
becomes cumbersome and confusing.

Is it possible to never use the Query Builder at all and therefore create
ALL queries in the VBA code? Do you 'real' programmers out there try to do
that or do you make good use of the Query Builder, or a happy balance
between the two?

Laura TD
lauratd
at
ltdsystems
dot
co
dot
uk
 
laura said:
I'm still very much at the learning stages. A lot of my programs rely on the
Query Builder - it's quick and easy to understand and implement. However, I
am finding that the list of queries grows and grows and that in itself
becomes cumbersome and confusing.

Is it possible to never use the Query Builder at all and therefore create
ALL queries in the VBA code? Do you 'real' programmers out there try to do
that or do you make good use of the Query Builder, or a happy balance
between the two?

Laura TD
lauratd
at
ltdsystems
dot
co
dot
uk
Click to expand...
 
It's possible to code all your queries, and there are programmers who enjoy
doing that.
Personally, I use the query builder a good deal of the time, because it's
fast and reliable, but use code when I need flexibility the QBG doesn't
offer me.

A consistent naming convention can be a big help in keeping queries sorted
out.
You can also put them in groups you define using "Groups" in the database
window.

HTH
- Turtle
 
Hi, Thanks for your input. I thought much the same - to use the Query
Builder when it's easier. The thing is that I found that I was using it even
for the simplest Queries and as I said, filling up the window with so many
queries - even with a reasonably consistent naming convention.

Your suggestion to use the "Groups" has interested me - I am not sure I
understand, can you explain?

Laura TD
lauratd at ltdsystems dot co dot uk
 
laura said:
Hi, Thanks for your input. I thought much the same - to use the Query
Builder when it's easier. The thing is that I found that I was using it even
for the simplest Queries and as I said, filling up the window with so many
queries - even with a reasonably consistent naming convention.

Your suggestion to use the "Groups" has interested me - I am not sure I
understand, can you explain?
Click to expand...

The RecordSource for a form can be a query that does not display as an object in
the query window. So can a Report. I do this whenever possible because it is
more self-documenting and for the reason you cite, to reduce the sheer number of
queries in the db window.
 
Assuming that you are using at least Access 2000, when you look at your
database window, you'll find on the left-hand side there's a list with a bar
for Objects like Tables, Queries, Forms, Reports...
At the bottom of this list is a bar labelled "Groups", with one default
entry "Favorites".
You can right-click on Favorites and create a New Group, with whatever name
you like, for example "Queries for frmReportSelect".
Now click on Queries, to display your list, and drag any queries you want
into this group.
Note that what you get in the group is actually a shortcut - the query
itself is still listed under Queries.
Also, if you like, you can drag frmReportSelect (or any other object)
into the group - it doesn't have to be all queries.

This is just another way to organize the objects in your database.

HTH
- Turtle
 
Rick,
object in the query window. So can a Report. I do this whenever possible
because it is more self-documenting <<

If it does not display as an object in the query window.. where is it? In
the VB Code? What MacDermott was suggesting was to use the Groups to
organise the objects, but I do not think this is what you mean, right? It is
for this 'self-documenting' reason that I wish to push more into the actual
coding if I can. Is this the way I should be thinking?

Laura TD
 
Thank you, yes, I get the idea - it does not reduce the amount of queries
etc in the Queries window, but you can at least put things that relate to
each other together. I understand that all I will be doing in fact is just
putting shortcuts there, not the actual object. Thanks for the suggestion, I
will try to do it.

Laura TD
 
laura said:
Rick,

object in the query window. So can a Report. I do this whenever possible
because it is more self-documenting <<

If it does not display as an object in the query window.. where is it? In
the VB Code?
Click to expand...

It is stored as a string in the RecordSource property. Internally it is parsed
and stored the same as a query in the db window, it is just not displayed there.
 
Very sorry for sounding so dim, but I still am not with you - do not
understand what you are saying.

Laura TD
 
laura said:
Very sorry for sounding so dim, but I still am not with you - do not
understand what you are saying.
Click to expand...

Let's say you have a form bound directly to the table "SomeTable". If you
look at the RecordSource property for that form in design view you will see
the entry "SomeTable" (without the quotes). Likewise if it were bound to a
saved query "SomeQuery" you would see the entry "SomeQuery" in the
RecordSource property.

You could also enter in the RecordSource property the string...

SELECT * From SomeTable

That SQL string is a query, but you will not find it in the db window
because it was not explicitly given a name and saved. You can even press
on the build button [...] to the right of the RecordSource property and it
will bring up the Query Design grid. From there you could add tables,
fields, calculations, etc., just as you would with a "normal" query and
when you are done the SQL statement for that query will end up in the
RecordSource property of your form/report.
 
OK.. I gotcha... many thanks... that's clear and also probably a "tidy" way
to program. Some of my programs have too many queries, some of which are
relatively small and could be tucked away in the RecordSource. Thanks again
for your patience, Rick.

Laura TD

Rick Brandt said:
laura said:
Very sorry for sounding so dim, but I still am not with you - do not
understand what you are saying.
Click to expand...

Let's say you have a form bound directly to the table "SomeTable". If you
look at the RecordSource property for that form in design view you will see
the entry "SomeTable" (without the quotes). Likewise if it were bound to a
saved query "SomeQuery" you would see the entry "SomeQuery" in the
RecordSource property.

You could also enter in the RecordSource property the string...

SELECT * From SomeTable

That SQL string is a query, but you will not find it in the db window
because it was not explicitly given a name and saved. You can even press
on the build button [...] to the right of the RecordSource property and it
will bring up the Query Design grid. From there you could add tables,
fields, calculations, etc., just as you would with a "normal" query and
when you are done the SQL statement for that query will end up in the
RecordSource property of your form/report.
Click to expand...
 
Back
Top