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

Question on multiple forms and referencing data

P: n/a
Hello everyone -

I've been developing an incident tracking and reporting system for an
emergency services outfit that I work with part time. It's going
well, except for one fly in the ointment.

The situation is this - I have a dispatch form that is used by
dispatchers to track incidents. An incident number is automatically
assigned with an AutoNumber field once a dispatcher initiates an
incident by opening the dispatch form. I have fields to record the
times of the most frequently occurring events - report time, dispatch
time, on scene time, clear time, etc. However, each incident is
unique, so I also provided a way for dispatchers to record
miscellaneous event times (such as for "Patient refused treatment",
and so forth) by opening another, modal form and recording times and
event descriptions related to the incident. These records, stored in
another table on the "many" side of a one to many relationship, are
linked to the main dispatch record by specifying that the default
value of the "key" field is the value of the "incident number" text
box on the main form.

This works swimmingly until the dispatcher has to open a second
dispatch form to work another, concurrently occurring incident (a
frequent situation). All of the "main" information is captured
without a hitch for the second incident, but when the dispatcher uses
the modal form from the second dispatch form to record miscellaneous
event times, those events get assigned the incident number from the
FIRST dispatch form.

For example, let's say the dispatcher is working on incident number
122. He's going along, working the radio and recording times, when a
second alarm comes in. He opens a second instance of the dispatch
form and begins to record times for THAT incident, number 123. He
opens the modal "miscellaneous event times" form to record
miscellaneous times for incident 123, but finds later that all of them
have been assigned the 122 key, linking them with the previous, wrong
incident.

Any ideas on how to do this better?

Thanks!
Nov 12 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
On 15 Feb 2004 20:15:21 -0800, jb****@comcast.net (J. Black) wrote:

A couple of suggestions:
1: Store ALL event times in a 1:M table, not just the less frequent
ones.
2: Now you've done that, you can have a subform on the main Incident
form to record all these events. No more need for a popup form, and
never incorrect linking again.

-Tom.

Hello everyone -

I've been developing an incident tracking and reporting system for an
emergency services outfit that I work with part time. It's going
well, except for one fly in the ointment.

The situation is this - I have a dispatch form that is used by
dispatchers to track incidents. An incident number is automatically
assigned with an AutoNumber field once a dispatcher initiates an
incident by opening the dispatch form. I have fields to record the
times of the most frequently occurring events - report time, dispatch
time, on scene time, clear time, etc. However, each incident is
unique, so I also provided a way for dispatchers to record
miscellaneous event times (such as for "Patient refused treatment",
and so forth) by opening another, modal form and recording times and
event descriptions related to the incident. These records, stored in
another table on the "many" side of a one to many relationship, are
linked to the main dispatch record by specifying that the default
value of the "key" field is the value of the "incident number" text
box on the main form.

This works swimmingly until the dispatcher has to open a second
dispatch form to work another, concurrently occurring incident (a
frequent situation). All of the "main" information is captured
without a hitch for the second incident, but when the dispatcher uses
the modal form from the second dispatch form to record miscellaneous
event times, those events get assigned the incident number from the
FIRST dispatch form.

For example, let's say the dispatcher is working on incident number
122. He's going along, working the radio and recording times, when a
second alarm comes in. He opens a second instance of the dispatch
form and begins to record times for THAT incident, number 123. He
opens the modal "miscellaneous event times" form to record
miscellaneous times for incident 123, but finds later that all of them
have been assigned the 122 key, linking them with the previous, wrong
incident.

Any ideas on how to do this better?

Thanks!


Nov 12 '05 #2

P: n/a
Hi Tom -

Thanks for your response. I've already considered that, but the problem
is this - there are certain times that are always captured during an
incident, such as dispatch time, on scene time, clear time. There will
never be multiple "dispatch times" for the same incident, so it makes
more sense to me have a field on the "1" side of the 1:M relationship to
capture those. Those fields are 'hard wired' as [Dispatch_Time],
[ES_On_Scene_Time] and so forth, in the main table on the "1" side.

The primary feature of the "miscellaneous" event times are their
user-definability. The dispatcher provides the event description in a
generic "event description" field in the "Many" table, and records the
time.

I think what needs to happen is for me to be able to reference the
recordset from the dispatch form that the "miscellaneous incident times"
modal form was opened from, in code. I'm not really an accomplished VB
type yet, but this may be a good opportunity to dive in.

The one thing I want to avoid (which some people have privately
suggested) is simply having 4 or 5 identical copies of the dispatch form
and modal "miscellaneous" form, so I can specifically reference and
distinguish fields on each. I'd much rather give dispatchers the
flexibility to dispatch as many incidents at once as they need to,
rather than limit it to some arbitrary number. Plus, it seems extremely
inelegant.

Thanks for the input, Tom!
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 12 '05 #3

P: n/a
rkc

"J. Black" <jb****@comcast.net> wrote in message
news:9a**************************@posting.google.c om...
I've been developing an incident tracking and reporting system for an
emergency services outfit that I work with part time. It's going
well, except for one fly in the ointment.
<snip>
This works swimmingly until the dispatcher has to open a second
dispatch form to work another, concurrently occurring incident (a
frequent situation). All of the "main" information is captured
without a hitch for the second incident, but when the dispatcher uses
the modal form from the second dispatch form to record miscellaneous
event times, those events get assigned the incident number from the
FIRST dispatch form.


How are you determining what Incident Number is used by the model
form? Seems to me that passing it as a value in an OpenArgs parameter
would clear up any confusion.

Nov 12 '05 #4

P: n/a
On 16 Feb 2004 17:48:52 GMT, Joseph Black <jb****@comcast.net> wrote:

Inelegant: I agree. From your original post I figured you had already
worked out how to create multiple instances of a form (without
creating copies of your form). Then the task left is to tell the popup
who its parent is. I would probably pass in the IncidentID using the
OpenArgs argument of DoCmd.OpenForm.
I might also spnd some time with BringWindowToTop and equivalents to
ensure the user knows which popup belongs to which parent.

Even if you don't store all statuses in a 1:M table, you can still use
a subform for the miscellaneous ones. It cuts the number of forms in
half, allowing for a better user experience.

-Tom.

Hi Tom -

Thanks for your response. I've already considered that, but the problem
is this - there are certain times that are always captured during an
incident, such as dispatch time, on scene time, clear time. There will
never be multiple "dispatch times" for the same incident, so it makes
more sense to me have a field on the "1" side of the 1:M relationship to
capture those. Those fields are 'hard wired' as [Dispatch_Time],
[ES_On_Scene_Time] and so forth, in the main table on the "1" side.

The primary feature of the "miscellaneous" event times are their
user-definability. The dispatcher provides the event description in a
generic "event description" field in the "Many" table, and records the
time.

I think what needs to happen is for me to be able to reference the
recordset from the dispatch form that the "miscellaneous incident times"
modal form was opened from, in code. I'm not really an accomplished VB
type yet, but this may be a good opportunity to dive in.

The one thing I want to avoid (which some people have privately
suggested) is simply having 4 or 5 identical copies of the dispatch form
and modal "miscellaneous" form, so I can specifically reference and
distinguish fields on each. I'd much rather give dispatchers the
flexibility to dispatch as many incidents at once as they need to,
rather than limit it to some arbitrary number. Plus, it seems extremely
inelegant.

Thanks for the input, Tom!
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!


Nov 12 '05 #5

P: n/a
To determine the Incident Number for the modal form, I simply set the
"Default Value" property of the "Incident Number" field on the modal
form to equal the value of the "Incident Number" text box on the "main"
form that opened the modal form. It works with a single dispatch, but
once you open the second instance of the "main" dispatch form and try to
open the modal form from IT, the Incident Number defaults to the
"Incident Number" field on the FIRST "main" dispatch form.

I realized early on that I couldn't specifically reference the "main"
dispatch form's "Incident Number" text box (i.e. Forms!...etc.), but
even when I make it generic (i.e. Default Value set to
[Incident_Number]), it doesn't assign the correct Incident Number.

As I said, this is looking more and more like I'm going to have to do
some coding so I can KNOW specifically which "main" dispatch form the
modal form was opened from, so I can grab the "Incident Number" text box
value from that specific "main" dispatch form.

Alternatively, I've thought about (and tried) doing away with the modal
form and using a subform, with the "Incident Number" fields linked, and
the Default Value of the subform's Incident_Number field set to the
value of the Incident_Number text box on the parent form. Then, I get
an error when I try to move to the subform mid-dispatch to fill in a
miscellaneous time because the main form is bound to a table that
requires certain values to NOT be null - i.e. the important onces like
dispatch time and clear time.

Remove *nospam* to email me.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 12 '05 #6

P: n/a
Thanks again, Tom. I'm thinking the same thing now about the modal
pop-up form versus a simple subform. I'm liking the subform idea much
more now. Much simpler UI, easier for dispatchers to tell which
incident they're working with, and I can display their previously posted
miscellaneous incident times as well, so they don't duplicate one in the
heat of the moment (and it can get pretty heated, from what the
dispatchers have told me - three, four incidents going at one time;
working the phones, the radios, the alarm panels). Simpler is better.

Thanks again, and thanks to everyone who replied. I'm looking at
passing in the value from the OpenArgs parameter.

--------------------------------

Remove *nospam* to email me.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 12 '05 #7

P: n/a
J. Black,
I'd solve this as a data structure problem before I tackled it as a UI
problem. In VB what you would do is fire child copies of the parent form
with their own arbitrary id and the id of the parent form. But I'd guess
that if you work out the data structure correctly the UI problem will solve
itself.

"J. Black" <jb************@comcast.net> wrote in message
news:40*********************@news.frii.net...
To determine the Incident Number for the modal form, I simply set the
"Default Value" property of the "Incident Number" field on the modal
form to equal the value of the "Incident Number" text box on the "main"
form that opened the modal form. It works with a single dispatch, but
once you open the second instance of the "main" dispatch form and try to
open the modal form from IT, the Incident Number defaults to the
"Incident Number" field on the FIRST "main" dispatch form.

I realized early on that I couldn't specifically reference the "main"
dispatch form's "Incident Number" text box (i.e. Forms!...etc.), but
even when I make it generic (i.e. Default Value set to
[Incident_Number]), it doesn't assign the correct Incident Number.

As I said, this is looking more and more like I'm going to have to do
some coding so I can KNOW specifically which "main" dispatch form the
modal form was opened from, so I can grab the "Incident Number" text box
value from that specific "main" dispatch form.

Alternatively, I've thought about (and tried) doing away with the modal
form and using a subform, with the "Incident Number" fields linked, and
the Default Value of the subform's Incident_Number field set to the
value of the Incident_Number text box on the parent form. Then, I get
an error when I try to move to the subform mid-dispatch to fill in a
miscellaneous time because the main form is bound to a table that
requires certain values to NOT be null - i.e. the important onces like
dispatch time and clear time.

Remove *nospam* to email me.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Nov 12 '05 #8

P: n/a
Hi Alan -

Thanks. Can you be a bit more specific as to the mechanics of
approaching this as a structural, rather than UI, issue?

I really appreciate all the assistance.

Remove *nospam* to email me.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 12 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.