473,385 Members | 1,531 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,385 software developers and data experts.

Question on multiple forms and referencing data

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
8 1671
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
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
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
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
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
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
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
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Charles A. Lackman | last post by:
I am working on a application that has many custom made dlls. Actually, for this app each dll is a different form. I am able, with no problem to reference and instantiate them to use their public...
6
by: Tim | last post by:
Hello everyone. I visit this board pretty regularly but have never posted. My question is an application architecture question... so hopefully it's okay to post in the dotnet general forum. I...
55
by: Steve Jorgensen | last post by:
In a recent thread, RKC (correctly, I believe), took issue with my use of multiple parameters in a Property Let procedure to pass dimensional arguments on the basis that, although it works, it's...
4
by: Dave Edwards | last post by:
I understand that I can fill a datagrid with multiple queries, but I cannot figure out how to fill a dataset with the same query but run against multiple SQL servers, the query , table structure...
1
by: Tom | last post by:
I have a large application; lots of forms, multiple dynamic DLLs, etc. I also have, in the appliation, a general 'Preferences' class object (which is in itself a separate DLL, and I just include a...
3
by: cmay | last post by:
I was reading the article "Performance Optimization in Visual Basic ..NET" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchperfopt.asp. One section...
34
by: Mathieu Trentesaux | last post by:
Hello I downloaded Office 2007 for this reason : It seems, once again, that it is impossible to save any modification done in a VBA library, from the main project in Access. The save button...
20
by: tshad | last post by:
Using VS 2003, I am trying to take a class that I created to create new variable types to handle nulls and track changes to standard variable types. This is for use with database variables. This...
4
by: nottarealaddress | last post by:
I'm trying to get my feet wet in VB2005 (our new standard at work after officially stopping new development in VB6 about a month ago). I'm working with a simple sql 2005 table of 50 entries, one...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...
0
by: ryjfgjl | last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.