Re: Basic Question for Lookups.

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

>From Vincent "My advice is, if you find them helpful, use them." You and
anyone who might want to maintain your application would also need to
understand them which many Access users don't.

It will be interesting to see the amount of traffic generated in these news
groups when Access 12 comes out with multi-select lookup fields in tables
:-( Most of us seasoned old guys (and some younger) are fairly passionate
against lookup fields and other mis-features.

--
Duane Hookom
MS Access MVP


"Vincent Johns" <vjohns@xxxxxxxxxxxxxxxxxx> wrote in message
news:NwWof.35958$q%.1485@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Bernard Piette wrote:
>
>> Wow, another very insightful answer from Vincent.
>>
>> I've found the wizard to be SUPER easey to use and need a rather strong
>> argument as to why I should stop if at all I should stop, what do you
>> both think? So to be sure, is there actually anything technically
>> incorrect by using lookups, am I breaking some knid of database rule.
>> Bernard
>
> As far as breaking rules is concerned, the link that Duane cited,
> http://www.mvps.org/access/lookupfields.htm, lists some reasons not to use
> Lookup properties. I personally think these reasons are inadequate,
> especially vis-à-vis foreign keys in Tables, and very especially if those
> foreign keys have no other purpose than to act as keys (which is how I
> usually use them).
>
> You do need to remember that the datum stored in a field with a Lookup
> property is NOT what you see in Query Datasheet View or Table Datasheet
> View, but for me that's a small price to pay for being able to see
> something meaningful there.
>
> Whether you choose to use Lookup properties or not doesn't really have
> much effect on the structure or contents of your database; the Lookups
> merely affect the appearance. My advice is, if you find them helpful, use
> them. Otherwise, get rid of them. Or you could use them for some foreign
> keys and not for others.
>
> For anyone else using your database, I suggest that you provide Forms and
> Reports that always hide the raw key values (unless the keys are also
> employee badge numbers or are otherwise meaningful).
>
> -- Vincent Johns <vjohns@xxxxxxxxxxxxxxxxxx>
> Please feel free to quote anything I say here.


.

Relevant Pages

  • Re: transaction disabling
    ... All this is internal to the database. ... couple of fields to the new/changed lookup key values. ... I am doing this as I have a dynamic query building form that users ... The filter keys are higher in the ...
    (microsoft.public.sqlserver.server)
  • Re: Attempting to allocate already allocated array?
    ... subroutine SUDA(arr_shape, keys, unique_inds, res) ... integer:: i, j, k, ind, n ... lookup and res initialised to zeroes ...
    (comp.lang.fortran)
  • Re: Lookup Tables, the right way?
    ... If you are defining a database table that requires a lookup table, ... then the foreign key between the two tables should be a character ... there's the question of surrogate keys versus natural keys. ...
    (comp.databases.theory)
  • Re: Overriding iadd for dictionary like objects
    ... the value, hence the second lookup. ... must effort has gone into optimizing dict lookup. ... I made a DictMixin where the keys are filenames and the values are the ... It was very simple and easy to do thanks to DictMixin. ...
    (comp.lang.python)
  • Re: transaction disabling
    ... query scans the 5 million rows how many of those will actually meet the ... > (from subgroups to group, from fiscal week keys to fiscal month keys, ... The lookup tables are ... By filtering the large table directly by using these stored ...
    (microsoft.public.sqlserver.server)