Help! Two forms for one table?

Hello,
I am developing a process management system. I have one screen that a end
user would enter "measurements" against each process. The process has both
Success measures and Red Flag Measures. My initial thought was one table,
then categorizing what the measure indicated. The problem is the end users
(being typical end users and not wanting it to be confusing) would like a
data sheet form for the success measures and a separate data sheet form for
the red flags. I do not want to put these two measures into two different
tables, but cannot figure out how to have one table on a form (which is
linked to a prior process form) have two forms (on the same page - 1 for
success / 1 for redflags) point to the same table and have the data be
accurate. I have hit a mental block - does anyone have any thoughts?

Thanks all!

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...arted/200602/1

Create two forms (ditch the wizard)
on the first form set the form's control source to the table in
question. open the field list and drag the fields relating to success
measures onto the form. If there is a yes/no field or similar which
defines the process as a success then include it. Set it's default to
-1 for yes or whatever is appropriate for the field. set it's locked
property to yes so that this cant be changed.

Do the Exact same for the second form except drag in the fields related
to Red Flag Measures. again include you field defining it as a success/
Red Flag and set the default to the appropriate value and set the
locked property to yes.

It's hard to be more specific without know ing more about the fields in
your table.

Just some thoughts::

This might be a good oppurtunity to take a close look at your 'measurement'
process. If users are taking some sort of measurement (e.g. 12.001 mm)
then applying an acceptance rule (Ok if 12.0 mm) (not ok if =12.0) then
you may want to record the actual measurement and provide the logic in your
database application. That way it is a simple matter to 'adjust' the
acceptance rule, and you have the 'raw data' available for future useses
(e.g. re-evaluation of the accept, reject crtieria).

Example you may find that 99% of your failures are only .001mm out of spec
and after a careful engineering review you can say that you really should
allow up to 12.003 mm to be acceptable -- reducing your reject rate by
99.9%. With no 'real cost'


Then you only have to provide a place to record 'measurements' with
time\item measured\how measured\ results.

Note: I really like to record the actual observation, if at all possible.

Ed Warren.


"Kathie G via AccessMonster.com" u2388@uwe wrote in message
news:5ba30f0cd80d7@uwe...
Hello,
I am developing a process management system. I have one screen that a end
user would enter "measurements" against each process. The process has both
Success measures and Red Flag Measures. My initial thought was one table,
then categorizing what the measure indicated. The problem is the end
users
(being typical end users and not wanting it to be confusing) would like a
data sheet form for the success measures and a separate data sheet form
for
the red flags. I do not want to put these two measures into two different
tables, but cannot figure out how to have one table on a form (which is
linked to a prior process form) have two forms (on the same page - 1 for
success / 1 for redflags) point to the same table and have the data be
accurate. I have hit a mental block - does anyone have any thoughts?

Thanks all!

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...arted/200602/1

Just wanted to say that the first suggestion is the one I went with. Thanks
for the 2nd suggestion as well but the measurements are performance based non-
statistical (basically a sentence that states how you know the process is
successful.) This organization has not yet developed a standardized metric
on how organizationally they are measuring up.

Thanks again. The first suggestion worked well - not sure but I tried
that the first time and it did not work - and the 2nd time was a charm.

Ed Warren wrote:
Just some thoughts::

This might be a good oppurtunity to take a close look at your 'measurement'
process. If users are taking some sort of measurement (e.g. 12.001 mm)
then applying an acceptance rule (Ok if 12.0 mm) (not ok if =12.0) then
you may want to record the actual measurement and provide the logic in your
database application. That way it is a simple matter to 'adjust' the
acceptance rule, and you have the 'raw data' available for future useses
(e.g. re-evaluation of the accept, reject crtieria).

Example you may find that 99% of your failures are only .001mm out of spec
and after a careful engineering review you can say that you really should
allow up to 12.003 mm to be acceptable -- reducing your reject rate by
99.9%. With no 'real cost'

Then you only have to provide a place to record 'measurements' with
time\item measured\how measured\ results.

Note: I really like to record the actual observation, if at all possible.

Ed Warren.

Hello,
I am developing a process management system. I have one screen that a end
[quoted text clipped - 12 lines]

Thanks all!

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...arted/200602/1

Glad it worked out for you - looking back at my answer, i think i could
have explained it better... also, i never mentioned that you would need
a filter on the forms to filter out successes from the red flag form
and visa versa. but if it is working for you i guess you figured that
bit out! Actually better yet, have the record source as a query on the
table and filter out undesired records there.