Use multiple ListBoxes to filter records?

[Ralph2]

Some time ago with a lot of help from this group I made a reasonably
successful database to keep track of our shop drawings. However the
searching mechanism is too complicated for the occasional user and I
would like to change the whole process.

I would like to duplicate the layout of my form... but each field
becomes a simple "searching" ListBox. On completing any one search
field all the rest are filtered to this value. Subsequent entries in
other ListBoxes further filter the remainder until the number of
records is down to a manageable level.

Is such a searching scheme possible? I use this process to go directly
to a single specific record based on the (unique) drawing number using
code from O'Reilly's Access Cookbook. However in my attempts to use
more than one instance ends in failure. I suspect the solution would
involve dynamically building a query which then would become the basis
for the next ListBox... But I need some major help, advice or possibly
a sample that uses this searching method where I can study the code to
use in my application.

My DB has some 6000 and counting records with 9 fields in each one but
not all the fields have data in them.

Thanks for any help, advice or encouragement.
Ralph

[Ed Robichaud]

Rather than the user interface you propose, how about a filter by form setup
(different from the data entry form) that uses a collection of combo boxes
to set a query's criteria.

In the header of your selection/filter form, put unbound combo boxes for
each field you wish to search on. In the query (which is the record source
of the form) make the criteria something like:
Like IIf([forms]![myForm]![myCombo] Is
Null,"*",[forms]![myForm]![myCombo])

Add a command button to run the query, and set the form's detail section to
"continuous form" to show multiple records that mat result from the
selection. In the form's footer, you could add a command button to open a
linked single record form for any record in the continuous detail section.

-Ed
"Ralph2" <no*******@hotm ail.com> wrote in message
news:1v******** *************** *********@4ax.c om...

Some time ago with a lot of help from this group I made a reasonably
successful database to keep track of our shop drawings. However the
searching mechanism is too complicated for the occasional user and I
would like to change the whole process.

I would like to duplicate the layout of my form... but each field
becomes a simple "searching" ListBox. On completing any one search
field all the rest are filtered to this value. Subsequent entries in
other ListBoxes further filter the remainder until the number of
records is down to a manageable level.

Is such a searching scheme possible? I use this process to go directly
to a single specific record based on the (unique) drawing number using
code from O'Reilly's Access Cookbook. However in my attempts to use
more than one instance ends in failure. I suspect the solution would
involve dynamically building a query which then would become the basis
for the next ListBox... But I need some major help, advice or possibly
a sample that uses this searching method where I can study the code to
use in my application.

My DB has some 6000 and counting records with 9 fields in each one but
not all the fields have data in them.

Thanks for any help, advice or encouragement.
Ralph

[pietlinden]

Ralph,
normally, one would use comboboxes for this. using listboxes is
possible, but a lot harder, because you have to build the filter for
the next listbox on the fly through code. The problem is that if you
have the MultiSelect property set to anything but None, then you have
to loop through that collection and write the Where clause for
yourself.
At any rate, explanations/examples of doing what you want with
comboboxes and listboxes are here:

http://www.mvps.org/access/forms/frm0028.htm

[Tim Marshall]

pi********@hotm ail.com wrote:

At any rate, explanations/examples of doing what you want with
comboboxes and listboxes are here:

http://www.mvps.org/access/forms/frm0028.htm

This is a great article, but I prefer to use the on got focus event for
the combo rather than the afer update event of the combo just selected.
I find it much easier to manage this way, especially if you have
several combos affecting the recordsource of another.

Also, the idea of having an initially empty recordsource for the
table/query rowsources of the dynamic combo boxes is an important idea a
lot of people miss, especially when dealing with a lot of records. If
you have your boxes with an initial rowsource, these all have to be
calculated and run before the form is fully loaded. With empty
rowsources, the form loads very quickly.

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Tim Marshall]

Tim Marshall wrote:

This is a great article, but I prefer to use the on got focus event for
the combo rather than the afer update event of the combo just selected.

To follow up - some may say this requeries the combo box even if you've
made no new choices when you go back to it. So I do this (air code):

Private Sub cboBldg_GotFocu s()

Dim strSql As String
Dim strCurRowSource As String 'current row source
Dim booC As Boolean 'is it necessary to create/recreate the row
source?
Dim strMsg As String

SysCmd acSysCmdSetStat us, "Wait, retreiving building list"

strCurRowSource = Me.cboBldg.RowS ource 'Current rowsource SQL

<snip construction of strSql for new row source which depends on
value of other combo boxes and possibly other controls (option groups
for sort order, etc>

'check to see if current row source SQL is the same - if different,
revise rowsource
'if no row source (strcurrowsourc e = "") create new SQL

booC = False

If strCurRowSource = "" Then

booC = True

Elseif strCurRowSource <> strSql Then

booC = True

End If

If booC = True Then Me.cboBldg.RowS ource = strCurRowSource

Exit_Proc:

SysCmd acSysCmdClearSt atus

Exit Sub

End Sub

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Tim Marshall]

Crumbs, forgot the essential requery (that's what you get with air code!):

Tim Marshall wrote:

Private Sub cboBldg_GotFocu s()

Dim strSql As String
Dim strCurRowSource As String 'current row source
Dim booC As Boolean 'is it necessary to create/recreate the row
source?
Dim strMsg As String

SysCmd acSysCmdSetStat us, "Wait, retreiving building list"

strCurRowSource = Me.cboBldg.RowS ource 'Current rowsource SQL

<snip construction of strSql for new row source which depends on
value of other combo boxes and possibly other controls (option groups
for sort order, etc>

'check to see if current row source SQL is the same - if different,
revise rowsource
'if no row source (strcurrowsourc e = "") create new SQL

booC = False

If strCurRowSource = "" Then

booC = True

Elseif strCurRowSource <> strSql Then

booC = True

End If

If booC = True Then
Me.cboBldg.RowS ource = strCurRowSource

me.cboBldg.Requ ery

End if
Exit_Proc:

SysCmd acSysCmdClearSt atus

Exit Sub

End Sub

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Ralph2]

On Mon, 07 Mar 2005 05:19:59 GMT, Ralph2 <no*******@hotm ail.com>
wrote:

Some time ago with a lot of help from this group I made a reasonably
successful database to keep track of our shop drawings. However the
searching mechanism is too complicated for the occasional user and I
would like to change the whole process.

I would like to duplicate the layout of my form... but each field
becomes a simple "searching" ListBox. On completing any one search
field all the rest are filtered to this value. Subsequent entries in
other ListBoxes further filter the remainder until the number of
records is down to a manageable level.

Is such a searching scheme possible? I use this process to go directly
to a single specific record based on the (unique) drawing number using
code from O'Reilly's Access Cookbook. However in my attempts to use
more than one instance ends in failure. I suspect the solution would
involve dynamically building a query which then would become the basis
for the next ListBox... But I need some major help, advice or possibly
a sample that uses this searching method where I can study the code to
use in my application.

My DB has some 6000 and counting records with 9 fields in each one but
not all the fields have data in them.

Thanks for any help, advice or encouragement.
Ralph

Thanks Ed R; pietlinden and Tim... will try your solutions and see if
I can make something work
Thanks again
Ralph