DWUTKA at marlow.com
DWUTKA at marlow.com
Mon Mar 29 15:27:27 CST 2004
Charlotte, that's not very nice. I have tested everything that you and Ken posted about this, as far as performance and bloat. Neither of those were true, and I posted step by steps on what I did to test it, and provided code when necessary. Space used by the Lookup fields is no more then if you just setup a relationship. And that is if you are using a lookup table/query. If you use a callback function, or a Value list, then there is no increase at all. No speed difference either, because it has been shown that it's just a property, which is only used in the GUI, whether it's a query or table interface, or if it's designing a form. (Once a form is designed, the lookup field can be overridden, since it is only a default control). Ken did use a scenario, a third generation db using tables setup originally with Lookups, as an example of how a lookup can cause trouble. He did show that they could be an issue. However, his example showed poor development along the way. (The original database was built and worked for it's purpose, the second generation was a copy of the first, but nothing was done to make it unique in it's purpose. The third generation could then not be simply a join between the first two.). Not saying Ken is a poor developer, just that his example assumed poor development along the way. That reinforces that if you don't know what you are doing, then things can go awry. But that holds true with LOTS of stuff within Access. So, tell me what's wrong, if a developer creates a database and uses a Lookup field. let's be specific. let's say Joe Schmoe builds a simple database for a client who wants to keep track of it's employees. In the Marital Status column, the developer sets the field to be a lookup, with a Value list of 'Married;Separated;Single;Divorced;Widow(er)'. What is wrong with that scenario? Let's say Joe Schmoe is on the wrong end of a Widowed employee, and the company needs a developer to upgrade the database to a newer version of Access. They hire someone from the middle east, who is a wiz at Access, but doesn't write english very well. Joe Schmoe's lookup field allows the foriegn developer to use the initial table design with no further ado. Is that not an advantage? I'm still trying to be civil, because you're right, I do believe in my opinion. That doesn't mean I can't change my opinion. When we had the discussion about using a Date Table, I did some testing, and found out that I was wrong, thus changing my opinion, based on facts presented. I'm still willing to do that, but I haven't been presented with facts, only scenarios which only reinforce the 'you must know what you are doing' clause. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Charlotte Foust Sent: Monday, March 29, 2004 2:44 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Lookup Fields in Table Design Forget it. You insist that your opinion carried the day. Go right ahead and believe it, but don't expect everyone else to agree. Charlotte Foust -----Original Message----- From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com] Sent: Monday, March 29, 2004 11:31 AM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Lookup Fields in Table Design What's my opinion? The 'nay-sayers' have not shown a good valid reason why it is 'wrong' to use them. All evidence points to the fact that they do their job, and if you know what you are doing, then use them if you want. I have been reading all of the posts on this thread, have ya'all actually posted a valid 'doomsday' catch all, that I missed? Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Charlotte Foust Sent: Monday, March 29, 2004 1:22 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Lookup Fields in Table Design NOT! That's your opinion, Drew. Not sacred writ. Try not to get them confused. <g> Charlotte Foust -----Original Message----- From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com] Sent: Monday, March 29, 2004 10:54 AM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Lookup Fields in Table Design And that is exactly why I jumped into the thread. There are a lot of 'myths' about Access. Most of them are perpetuated by personal preferences, rather then actual issues. In your case, of a value list, there is NO drawback, because the value list would just import or link without a hitch, and server side db's would just ignore them if imported. However, you are a good example of why I posted what I did, because you were under the impression that it was wrong to use them. That was just mis-information. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John Bartow Sent: Monday, March 29, 2004 11:58 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Lookup Fields in Table Design Dittos - exactly my point too. And I want to thank everyone who helped out in the discussion - "nay-sayers" and "sayers" alike! Without a quality discussion between people who disagree on the matter I would have learned very little and the archives would have just been cluttered up with flames. It was an eye opener for me since I had been the one who had assumed there was something terribly wrong with using the lookup property. My assumption was not even based on what was eventually brought as the problem. I had assumed the whole buggaboo was about using delimited lists as the default lookup. The one time I did use the lookup property it seemed to be the only reasonable way to handle the situation (it was specified that the users were to be given free reign to the database window). It bugged me that I had used it since so many people had recommended against it. Now I feel totally justified about doing it the way I did. I used defined queries based on the normalized relationships that existed in the database as the default lookup property. This is what should have been used even if the defaults were not set up. The only difference lies in the fact that it saves steps when adding controls to forms and - the reason I did it - it uses the correct lookup values displayed in the data sheets so some user isn't going to come along and try and type auto numbers in and miss by one or two digits. If anyone ever changes the structure they should certainly check to make sure the queries all work properly so it shouldn't even cause problems for some of the more extreme cases that were brought up. So William and Andy - to make up for your inconvenience I'll buy you a mug or two when you stop in to Winneconne someday :o) John I just hope that people starting out in Access read the thread, and realize that not everything that is 'recommended' about Access is based on fact. That their goal in their development career should be to learn everything that they can with the development tool of their choice, and not just take things at face value. Drew -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com