DWUTKA at marlow.com
DWUTKA at marlow.com
Fri Mar 26 14:28:47 CST 2004
And like I said to Gustav, that is EXACTLY why I got into this thread. You can't really understand something, if you can't challenge stuff with a 'why not?'. And if the answer doesn't really wash, you need to drill down until you find the real 'why not', or until you find that you 'can'. It's like the SendKeys issue. Yes, Sendkeys has a bug, which causes the Numlock key to change state. WAY too many people say that you should NEVER use the SendKeys statement, unless it's a dire emergency. That's wrong. Because, if you use the Sendkeys statement, emergency or not, you are probably going to run into the bug. So you have to see if you can handle the bug, which you can. You check (and store) the state of the numlock key before Sendkeys, and then check (and restore if necessary) the state of the numlock key afterwards. So, if you use the Sendkeys in a spot where you absolutely have to, you should put in code to handle the bug, which then makes the Sendkeys function safe. Since it's safe to use then, it also makes it safe to use everywhere else. Granted, the real reason you shouldn't use sendkeys, is because you are trying to 'mimic' a user interaction, and in cases where there is a strictly code interaction method, you should use the code interaction method instead, because there is no chance of the users 'goofing' what you are sending. (A user might try to type into a box, or react to an interface, but if you can avoid the interface, and do what you need to, through code, then you eliminate that risk). Almost makes you wonder if Microsoft put the Numlock bug into Sendkeys to give them a reason to tell people not to use it! LOL There are a LOT of little things that are put out as 'law', but are really guidelines, or methods that people used to get to a certain spot, and then stopped. Like hiding the Access window. If you hide the Access window, you need to have an open 'pop-up' form visible, for the users to interact with the database. If you close that form, but don't 'show' Access, you now have an open instance of Access, that looks like you can't get to it. A lot of people/sites warn that you have to close it through the Task Manager. Not true, you just need to know more code, because you can tell windows to make the Access window visible again. It's not too difficult, because the Microsoft Access window has a class of OMain, which is unique to Access. (every version so far (97 and up, don't know about previous versions). It is also said that you need to set the modal property to true in A2k and up. Which is also not true, you can get around it with another ShowWindow() API call. All I am saying is that I'm tired of hearing things that are 'bad practice', when they are really just preferences. No spaces in table names, that's a bad practice, there is solid reasoning behind it. Using SendKeys isn't bad practice. Using it willy nilly, and not 'capturing' the bug with Numlock code, THAT's bad practice. But using it when necessary, and protecting against the bug, that's not bad practice, in fact, that's GOOD practice. Just my humble opinion. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John Bartow Sent: Friday, March 26, 2004 11:55 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Lookup Fields in Table Design Hi Gustav: "moot" would be the correct word - if it really applied ;o) I actually do things the way you describe. But I do it based on other developers advice that I never really questioned before. I believe the discussion is: why not (use the lookups property)? For instance, when I did use it on a particular project where it fit the need it did make form design quicker and easier (once I adjusted to it). It makes placing combo boxes (in my case to lookup a foreign key) very simple. Just drag the control out and forget about it. A one step process. Being suspicious that it would cause problems later I went back to how I had done it previously. The 2 or 3 extra steps when placing a combo box really isn't adding a lot of overhead to my overall development time. But it does beg the question: why not? John B. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Gustav Brock Sent: Friday, March 26, 2004 11:04 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Lookup Fields in Table Design Hi all lookuppers Maybe I'm dense but - as mentioned by Ken - if you really need the feature of lookup fields (and I did once for some superuser administrative tasks performed once a year or never, thus not justifying design of eight forms) you simply - in a separate frontend database - create some queries retrieving exactly the fields you need (which excludes the ID), readable aliases for the fields, and lookups as needed. Then everybody is happy. You avoid fiddling with the table design and you can easily redesign the queries if and when needed and you take advantage of a feature of Access which can be handy. And this discussion becomes moot (isn't that the wording for such a situation you use "over there"?) /gustav > Here are "The Evils of Lookup Fields in Tables" from Dev's website: > A Lookup field in a table displays the looked-up value. For instance, if a > user opens a table datasheet and sees a column of company names, what is in > the table is, in fact, a numeric CompanyID, and the table is linked with a > select statement to the company table by that ID. > Any query that uses that lookup field to sort by that company name won't > work. Nor will a query that uses a company name in that field as a criteria. > If a user creates a combobox to select the company using a value list, the > data in the table can be over-written. > Another relationship is created which then creates another set of indexes > when a Lookup field is created, thus bloating the database unnecessarily. > If a combobox based on the lookup is used in a form, and a filter is > applied, the persistent filter effect of Access often saves the filter and > the next time the form is opened, there will be a prompt for the value > (which cannot be provided, thus creating an error). > Reports based on the lookup field need a combobox to display the data, > causing them to run more slowly. The underlying recordsource can also be > modified to include the table, however the index, (unless it was set up > within a proper relationship) may not be optimized. > Lookup fields mask what is really happening, and hide good relational > methodology from the user. > The database cannot be properly upsized to, or queried by, another engine > (without removing all the lookup fields) because no other engines use or > understand them. > If security is implemented, permissions to tables is usually denied, and > RWOP queries are used for data access. There will often be errors that there > are no permissions on a specific table that isn't even being used in a query > (because the lookup field is). If the queries are nested or complex, it can > take some time to track down the lookup that's causing the error (that is, > if it occurs to you). > http://www.mvps.org/access/tencommandments.htm -- _______________________________________________ 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