Re: Synchronizing the Main form and six (6) subforms?

Let me turn the question around - what would you like it to do?


"phmckeever" <phmckeever@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6C9A9F54-86D3-45D1-9B20-161E09B35661@xxxxxxxxxxxxxxxx
> Also, with the one table option, what do I do when someone wants more
> information on someone already in the database. I plan 'no dups' on the
> primary key field , SSNumber, which drives the data collection?
>
> "phmckeever" wrote:
>
> > I am understanding everything you are saying, except for the "ShipType"
> > field. Am I to add this field to my one big table; and, how do I store
the
> > data on the 'shiptype' that I pick. I need some type of data form to
open so
> > that I can enter information on the shipping method. Evidently, I am
missing
> > something you are saying. I hear one table and the 'Ship Type' field
for the
> > ListBox. What am I missing?
> >
> > "Rob Oldfield" wrote:
> >
> > > Slightly tricky. It actually comes down to how you organise your
table
> > > structure. It sounds like, at the moment, that you have one table for
each
> > > of the shipping methods. I'd say that that is a structure to avoid -
unless
> > > the fields that you need to store for each one are fundamentally
different.
> > > If they're not, then I'd just store that information in fields on the
main
> > > table (although you will end up with fields which *must* be blank - if
you
> > > have a delivery reference that is applicable for FedEx, then you're
never
> > > going to have that data for Interoffice). Having said that,
reorganising
> > > your data in this way might cause problems later on dependent upon
what else
> > > you want to do with the data.
> > >
> > > Either way, you're going to need to control which controls/which
subform to
> > > display. I'd definitely suggest losing the command buttons - a simple
drop
> > > down list (bound to a field ShipType) showing each of the methods is
going
> > > to be better.
> > >
> > > You're then going to need to run code in both the AfterUpdate event of
that
> > > control (so that the relevant controls are displayed when ShipType is
> > > updated) and also the Current event of the form (so that the same
thing
> > > happens when the user moves from record to record). That will be the
same
> > > code in both cases and will need to include...
> > >
> > > if isnull(me.shiptype)
> > > 'hide all fields/subforms which are dependent upon knowing
ShipType
> > > endif
> > >
> > > so that nothing is available *until* the ShipType is entered.
> > >
> > > So - how different are the fields of data required for each method?
> > >
> > >
> > > "phmckeever" <phmckeever@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> > > news:D9B673AC-3E39-422F-B7F1-1480A058D05D@xxxxxxxxxxxxxxxx
> > > > On the main form, I have the basic information on the data I am
tracking.
> > > > However, one piece that could vary is how the final response was
shipped:
> > > > Federal Express, U.S. Mail, Hand Delivered, or Interoffice. For
these, I
> > > > have developed subform.
> > > >
> > > > Unfortunately, when a record on the main form is displayed, and you
don't
> > > > know up-front that it was shipped U.S. Mail and click the Federal
Express
> > > > Button, the first record for Federal Express is displayed, rather
that US
> > > > Mail. This record is displayed regardless as to whether it is the
method
> > > of
> > > > shipment for the main form record. How do I tie the correct method
of
> > > > shipment to the correct main record.
> > > >
> > > > In order to click the right delivery method button (Federal Express,
US
> > > > Mail....) for the displayed record, you have to know the method of
> > > shipment
> > > > upfront.
> > > >
> > > > I need for the coordination to automatically take place. When the
main
> > > > record is displayed, highlight the cmdButton for shipment type and
'gray
> > > out'
> > > > the other buttons..
> > > >
> > > > Can you help me with the code?
> > > >
> > > > "Rob Oldfield" wrote:
> > > >
> > > > >
> > > > > What do you mean by 'synchronise'? The usual relationship that
exists
> > > > > between records on a main form, and records on a subform is just
that a
> > > one
> > > > > to many relationship applies between the two (controlled by the
master
> > > and
> > > > > child fields properties of the subform control). If you data is
in that
> > > > > form, then it would just be a case of each command button setting
the
> > > source
> > > > > object for the subform control, and also resetting the master and
child
> > > > > fields (me.SubformControlName.linkchildfields and
> > > > > me.subformcontrolname.linkmasterfields). It might be that you
don't
> > > always
> > > > > need to reset both - if the parent field for all six subforms was
an ID
> > > > > field then you wouldn't need to touch it.
> > > > >
> > > > > Does that make any sense to you?
> > > > >
> > > > >
> > > > > "phmckeever" <phmckeever@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
> > > > > news:499D9E3F-739B-4721-93AD-B4A463092BCE@xxxxxxxxxxxxxxxx
> > > > > > Microsoft Access 2003
> > > > > >
> > > > > > I have developed a Main Tracking form in Access. I have six
> > > cmdButtons on
> > > > > > the Main form that 'on-click' opens difference subform. How do
I
> > > > > > synchronizing the data in the Main form with the data in the
subform.
> > > Or
> > > > > can
> > > > > > this synchronization of a main form and six subforms be done?
As you
> > > may
> > > > > > have noted, I am extremely new at this.
> > > > > >
> > > > > > Any help is greatly appreciated.
> > > > > >
> > > > > > patricia
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >


.