Don't feel nervous about disagreeing with me, Phil -- not only am I not
always right, but I am no longer embarrassed to admit it. Once I had made a
fool of myself in public a certain number of times, it no longer held any
terror for me. <G>
What I was thinking was not that the table will always remain exactly as it
is, but that none of the existing values would be arbitrarily changed.
Assume that it might be more complex than "Truck", "Rail", "Ship", and
"Air" -- perhaps there might be several entries for truck shipment via
different companies. If all the shipments via "RoadHog Freight Lines" were
to be reassigned to "RedDirt Hauling Co" because RoadHog went bankrupt and
the two firms served the same region, it might be changed; if
"FasterFreight" qualified as a new trucking firm to be used, it might be
added. If "BentWings Air" went out of business, that number might be reused
for a different air carrier, or just left unused. It's all a matter of good
business judgement as to which changes would be appropriate -- that's the
reason that not just any user could be allowed to modify it.
If indeed it were only "Road", "Rail", "Ship", and "Air" and there wasn't
going to be a change until it became practical to ship via "Orbital Rocket",
you're right, there wouldn't be an advantage (generally speaking) to using a
table instead of hard coding the labels, unless the table had other uses as
well.
I suppose I could also imagine a "generic form" that could be adapted to
multiple uses by simply changing the tables that it used.
I rarely do that kind of thing, on the basis that "simpler is better" for
the kind of work I do (contract work that may have to be maintained by
someone else). It has surely cost some customers a lot of extra expense
because a developer got carried away and tried to make one "self-modifying"
object do when it would have been better to have several simpler ones, each
trivially simple to maintain. I have, I sadly report, been the person who
had to spend extra time to figure out a few complex self-modifying objects
before a simple change could be implemented.
Larry
"Phil Stanton" <phil@stantonfamily.co.uk> wrote in message
news:3fb013fe$0$107$65c69314@mercury.nildram.net.. .[color=blue]
> I feel very nervous at arguing with an expert such as yourself Larry, but[/color]
if[color=blue]
> the table isn't going to be changed, why not write the label.Captions
> directly
>
> Phil
> "Larry Linson" <bouncer@localhost.not> wrote in message
> news:R3Srb.32725$p9.25957@nwrddc02.gnilink.net...[color=green]
> > "Phil Stanton" wrote
> >[color=darkred]
> > > Sounds Dodgy. . . .
> > > and someone changes the table to Air,
> > > Road, Sea, Air, you will get the wrong
> > > answer.[/color]
> >
> > That would be the Lookup Table for "Ship By" and it should not be[/color]
> available[color=green]
> > for just anyone to go in and change, willy-nilly.
> >
> > In a developed application distributed to users, the users should have
> > neither direct access to the Table, nor to the Query Builder, nor to a[/color]
> Form[color=green]
> > to update that Table. It should also be declared with Referential[/color]
> Integrity[color=green]
> > and Cascading Update so that _valid_ updates to the key field by a[/color]
> developer[color=green]
> > would be carried forward to related tables (and a developer should know[/color]
> that[color=green]
> > you don't change the description of "Road" to "Air" in a lookup table --[/color]
> if[color=green]
> > not, then continuation of employment ought not be an option).
> >
> > Larry Linson
> > Microsoft Access MVP
> >
> >[/color]
>
>[/color]
