Filters on form created from query with filters

[liveinhope]

Using access 2013

I created a query and applied a filter in the query's design view/sql view (as distinct from applying the filters in datasheet view)

I used that query to create a form . That form only shows the rows that met the query filter criteria

My problem is this .. I cant find anything in the form to show what the filter criteria on the form is

can anyone help

 

[Micron]

I cant find anything in the form to show what the filter criteria on the form is

Because there isn't any - you put it on the query. You'd have to use something like a form label to show what the filter on the query is, assuming it's not dynamic. But why do it this way? Why not use criteria in the query itself to limit the records as opposed to applying a filter to it? If you need to filter the form further, or if the filter is dynamic (based on a form control value for instance) you can read/get the filter value since it is a form property.

 

[liveinhope]

That's what I did in the place .... probably should have worded this as "applied criteria in the query's design/view/sql view" so here's my reworded question

-I created a query and <s>applied a filter and </s>Entered selection criteria in the query's design view/sql view (as distinct from applying the filters in datasheet view)

I used that query to create a form . That form only shows the rows that met the query criteria

My problem is this .. I cant find anything in the form to show what the selection criteria on the query (and therefore my form) is
How can I find out ?

 

[Micron]

So you're saying the criteria is not dynamic because it is 'hard coded' into the query while in design or sql view.
Simplest solutions
- put a label on the form that displays the criteria that you simply type in as the label caption as text.
- if you don't want it to be continuously displayed, a message box could announce it when the form opens (might become annoying after a time).
- not my favorite idea, but you could create a calculated query field that adds that text, albeit to every record. You could then see the criteria in a form control bound to that field.
- you could probably pass the criteria as text to the form OpenArgs and dump it into an unbound form textbox (or as noted, as a message box).
- or if you are using an event to open this form, you could simply assign the text to an unbound form textbox in the Open event (or Load - shouldn't matter).

More complicated - define the criteria as a parameter(s) in design view (see property sheet) and get the query parameter in the Load event (not Open event) of the form. This will require a procedure to get the DAO parameter property of the DAO query definition object. While I've always used these object properties to pass parameters to a query in code, I've never gone the other way. I don't see why it can't be done as long as you've defined them in the query design as I mentioned. It would be the only way I could think of to get the criteria showing on the form if the criteria is dynamic.

 

[liveinhope]

I don't need to show the actual query-criteria on the form

I just want to be able to view/check "Does this form have any criteria that it's picking up from the query that I (or someone else) used to create the form "

Not a real problem if I create a query with some criteria then right away create a form from that query . In that scenario I remember which query I created the form from so I just open that query in sql or design from and I have my answer

But if its been a while I don't always remember which query I created the form from (or someone else may have created the form and I don't know which query the from came from )

Think I've got it know . is it the "record source" on the form's property sheet as in your final suggestion ? (if "yes" then that will do for the time being writing code to see the query criteria from the from is a bit beyond mu expertise at the moment but opening the query and checking out there is OK)

 

[Micron]

Yes, the form or report recordsource property defines the source of the records for the form or report. There are object naming conventions that can assist you - e.g. if the name begins with qry, frm, tbl, rpt or mdl, it's obvious it's for a query, form, table, report or module. So if the recordsource is qryCustomers, that should tell you what you need to know. Similarity can help: tblCustomers, qryCustomer, and rptCustomer (as an example); it's obvious these are related. Descriptive but short names also help: qryApndNewCust tells me what it does and to where without me having to play detective. Without having to open frmCustomer to check, I should be able to figure out what it's data source is by looking at query or table lists for related names. Where this doesn't have much effect is when the recordsource is a sql statment, but then, you can read that and figure it out.

There is also a property sheet available for these objects (right click on it) where you can put notes. Mousing over action queries will tell you what table it will affect.

 

[liveinhope]

thanks for that