[AccessD] Lookup Fields in Table Design

Ken, once again, you aren't reading what I posted.  Querries DO NOT care
what the DefaultControl property is.  Only the interface that you use to
view a query with does.

Okay, a unique feature.  I create an .mdb, to store data for a multiple UI
system.  The UI's are ASP, and VB.  Now, every once in a while, I jump into
the backend, to see how things are going.  I open up a few tables, here and
there, and just take a look.  No need for forms, no extra time wasted doing
anything other then looking at the tables in datasheet view.  However,
instead of seeing 'meaningless' ID's, I can see what they actually
represent, (and here's the catch)....IN THE TABLE'S DATASHEET VIEW. You just
cannot do that with any other approach.  Sure, you may mimic it, you may
jump up and down, and dance around, but it is just too plain and simple to
not use when you want too.  Other then the benefit I receive, there is no
other affect of having those fields set as lookups.  NONE. (Still haven't
seen a true performance issue presented by you yet!)

Drew 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
To: 'Access Developers discussion and problem solving'
Sent: 3/26/04 7:35 PM
Subject: RE: [AccessD] Lookup Fields in Table Design


You seem to be making more noise than actual rebuttal.

First, show me at least *one* unique feature that server-side,
table-level
field lookups gives me, that can't be duplicated using more broadly
accepted
techniques. Show me some intrinsic value.

Second, if you throw a grain of sand in the water, it doesn't make a
ripple.
So it is with this feature. The database community at large hasn't
looked at
table field lookups and said "Hot damn! let's break the client-server
model
and embed client UI elements in tables! Comboboxes, subforms ... hell
...
let's stuff entire forms in there, complete with underlying code!". So
you
have a query, which inherits all this stuff, and you drag it all over
from
the server so you can open ... a report. When you take this line of
reasoning to its logical conclusion, its easy to see that this whole
thing
goes against the standard, accepted way that database applications are
constructed. Data in this bucket. App in this other bucket.

Since you didn't refute the 'constructionist' bit, I assume that's what
you're admitting you are: throw in the kitchen sink, hope it helps, hope
you
catch all the places it doesn't, and where you miss things, hope it
doesn't
bite you.

Puh-lease.

Lets look at some what you say more closely:

>It doesn't affect that, BECAUSE it's a property that is only
>looked at by the Wizards, NOT by Jet, when retrieving the data.

Its used in queries too. Queries inherit this stuff from the table they
are
based on.

>Now, when it builds the indexes, JET does look at it, to determine
>if it needs to add indexes to help the listbox.  This is a guess,
>but I would be willing to bet, that what it is adding, is a quick
>index reference to show what the 'displayed' data for that field is.
>-Which is no more indexing, then if you just went and created the
>relationship in the first place!

Jet never spontaneously adds table indexes. If so, you would be able to
see
them in the table definition after thay had been created. Temporary
indexes
would be very expensive to create and then throw away. Prove your
assertions.

Thats all I have time for now. More later.

-Ken

-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com