By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,639 Members | 2,276 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,639 IT Pros & Developers. It's quick & easy.

Search button / form

P: n/a
Stu
Hi, I've been looking through the archives but can't find what I'm
looking for, or due to my limited experience with Access97, didn't
recognize it...
I've created a database that is going to be used for updating
procedures at several different sites, and am stumped at creating a
search feature. There is one main form with six subforms linked to it,
and I'm not sure the best way to set up the search parameters. I'm
still learning VB and Access, so I don't have the knowledge to write in
depth programs, but would like to know the ways that you all use. What
works, what doesnt work, where's a good starting point for a beginner.
Any advice would be greatly appreciated. If you need more details,
I'll be happy to prove them.

Thank in advance,
Stuart K.

Nov 13 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
I bet you want to search tables, not forms. What do these subforms
represent? What do you want to search, and what do you want to find?

Does any button wizard anything in the direction of what you are looking
for? If so, tell me which one, and how it differs from what you want.

Stu wrote:
Hi, I've been looking through the archives but can't find what I'm
looking for, or due to my limited experience with Access97, didn't
recognize it...
I've created a database that is going to be used for updating
procedures at several different sites, and am stumped at creating a
search feature. There is one main form with six subforms linked to it,
and I'm not sure the best way to set up the search parameters. I'm
still learning VB and Access, so I don't have the knowledge to write in
depth programs, but would like to know the ways that you all use. What
works, what doesnt work, where's a good starting point for a beginner.
Any advice would be greatly appreciated. If you need more details,
I'll be happy to prove them.

Thank in advance,
Stuart K.


--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html
For human replies, replace the queue with a tea

Nov 13 '05 #2

P: n/a
Stu
Tables, not forms, your right. I have tables and forms with similar
names to keep track such as frmTopicPlan and tblTopicPlan.
There is a main form called TopicPlan that has a primary key (record
number called Identifier) that links to other forms with the same
Identifier. The other forms are titled Deliverables, TrainRM,
TrainPlan, StdSpec, Tools, and CertGuide.
There is only one Deliverables record for each TopicPlan. All the
"other forms" follow suit with just one record per TopicPlan.
Currently everything is in seperate tables, but I'm not sure if it
should just be one BIG table that everything else references.
Background:
Basically, the company has different procedures at its different sites,
and it wants a way to create a new global-procedure, that eliminates
various site-level procedures. The various forms are the types of
procedures. I already have everything linked together and it works
well, but now I'm told to make a search field so that the user can pull
up/modify any of the procedures from any of the forms. This means I
need to be able to search Title and Description field on all six of the
"other reports" and need to search seven fields from the main form
(TopicPlan) consisting of:
TopicName, TopicOwner, Interfaces/Controls, Exceptions,
Transitions, Critical Success Factors, and Management Reporting.
One example would be search for the word "deisel" and ideally, I would
get every form returned that mentioned deisel in it.
Being fairly new to Access97, I'm not sure how or where to start.
Hopefully this hasnt been too hard to follow...

Nov 13 '05 #3

P: n/a
I get the impression your data structure is not optimal yet. Your
problem decomposes into two issues:

(1) what relation do various pieces of information have to the
Identifier? Ideally, all information in one record of a table should
depend on the primary key, the whole primary key and nothing but the
primary key. Depend meaning here: the information tells you something
about this record.

Once you know the direction to seek:

(2) finding data in fields is relatively easy. Create a button on the
form, create an event procedure for it (properties sheet, Events tab,
Click event: select [Event Procedure]; click the three-dot button, and
if asked, choose VBA procedure) and key in

docmd.FindRecord
Now press F1 for help

Stu wrote:
Tables, not forms, your right. I have tables and forms with similar
names to keep track such as frmTopicPlan and tblTopicPlan.
There is a main form called TopicPlan that has a primary key (record
number called Identifier) that links to other forms with the same
Identifier. The other forms are titled Deliverables, TrainRM,
TrainPlan, StdSpec, Tools, and CertGuide.
There is only one Deliverables record for each TopicPlan. All the
"other forms" follow suit with just one record per TopicPlan.
Currently everything is in seperate tables, but I'm not sure if it
should just be one BIG table that everything else references.
Background:
Basically, the company has different procedures at its different sites,
and it wants a way to create a new global-procedure, that eliminates
various site-level procedures. The various forms are the types of
procedures. I already have everything linked together and it works
well, but now I'm told to make a search field so that the user can pull
up/modify any of the procedures from any of the forms. This means I
need to be able to search Title and Description field on all six of the
"other reports" and need to search seven fields from the main form
(TopicPlan) consisting of:
TopicName, TopicOwner, Interfaces/Controls, Exceptions,
Transitions, Critical Success Factors, and Management Reporting.
One example would be search for the word "deisel" and ideally, I would
get every form returned that mentioned deisel in it.
Being fairly new to Access97, I'm not sure how or where to start.
Hopefully this hasnt been too hard to follow...


--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html
For human replies, replace the queue with a tea

Nov 13 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.