Query Question (2003)

I've been trying to create a query that will return all records containing the word "Lincoln" in a text box labeled "INDEXING." I want to end up with only records that meet this criteria, but which show all fields of those records. I haven't been able to do this with either the query wizard, or in Design view.

Here's what I've tried in Design View:
1. Select Queries
2. Create query in Design View
3. Selected my database in Show Table box.
4. Highlighted all fields in the upper box and dragged them down to the lower half of the screen.
5. All "Show" boxes are checked
6. Entered: "Like "Lincoln"" (in the Criteria row under INDEXING)
7. Selected RUN

All I get back is a datasheet view with all the correct field headings, but nothing returned -- just a single blank row.

I'm sure this must be one of the easiest queries in Access -- but I can't get it to work?!
Thanks for any help.

Re: Query Question (2003)

Thanks, Hans. I knew that worked in "Find," but didn't realize it applied to a query as well. One last thing -- is there a way to have these returned in the form I designed when entering this database? It's much easier to read.

Re: Query Question (2003)

Just tried and, yes, it does work fine. It looks like the only problem is that the filtered form can't be saved in the same way as a query is -- that is: if I save it, it looks like that will create a new database. Whereas, in saving a query, you don't recreate a whole new space-hogging item -- just the query terms are saved. Is that right?
Thanks

Re: Query Question (2003)

Sorry, I skipped a step in my explanation. I want to save the results of my queries/filters -- so I can retrieve this information as needed, without having to retype Like "*Lincoln*" each time. (The problem will come when I move to more complex queries/filters with several different criteria in different fields.) Does that make sense?

Re: Query Question (2003)

I think you meant a new table instead of a new database.

If you really need to store the result of filtering the data, you'd have to create a new table. This is very inefficient, and in general it's not a good idea. Can you explain what you want to accomplish?

Re: Query Question (2003)

Yes, I guess table is the right word, and it's that inefficiency I want to avoid.

Here's what I'm trying to do.

I have a table ~800 records and growing, that I'm using to store and retrieve information for a book I'm writing, non-fiction, history. Here's an example of one record. It includes:
-----------------
1. Subject field: "Supreme Court rules that EPA has power to regulate carbon dioxide."
2. Date field: 4/2/2007
3. Index field: "Supreme Court -- EPA -- George W. Bush -- carbon dioxide -- global warming"
4. Information: "In one of its most important environmental decisions in years, the Supreme Court ruled on Monday that the Environmental Protection Agency has the authority to regulate heat-trapping gases in automobile emissions." [There are several more sentences, but you get the idea]
5. Source field: "New York Times, April 3, 2007"
---------------------------------

There are several other fields but these are the most important.

The records go back three centuries. Here are some of the things I want to be able to do, without starting from scratch each time:

1. Find every quote from Teddy Roosevelt on the importance of forests.
2. Find all references to "conservation" between 1850 and 1920.
3. Find every mention of the Endangered Species Act in my database.

Sorry for the lengthy reply, but I'm hoping these examples make what I'm trying to do understandable.

Re: Query Question (2003)

OK, the idea is that you save the selection criteria as a query. While you're in the Advanced Filter/Sort window, you can save your current specification as a query using File | Save as Query or the corresponding toolbar button, and you can load a previously saved specification using File | Load from Query or the corresponding toolbar button.
Since, as you know, queries do not store the resulting data, only the filter/sort specification, the overhead of saving queries is small.