Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.databases.ms-access > #9154
| From | Hagen Weidlich <durragon@web.de> |
|---|---|
| Newsgroups | comp.databases.ms-access |
| Subject | Re: Managing changes to combo box contents when values are contained in a table |
| Date | 2014-03-14 22:14 +0100 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <lfvrg3$us1$1@speranza.aioe.org> (permalink) |
| References | <lfq2ka$mjk$1@dont-email.me> |
Am 12.03.2014 17:39, schrieb BobAlston:> ... > If a user subsequently decides to change the combo box list contents, > they could delete records (in the table feeding the combo box) that they > no longer need. Of course this would affect the historical data using > that combo box selection. The "proper" way around this is to set the > relation so that the entry could not be deleted if there are related > records with its key. Relational theory!! > > You can handle this by setting an "unused" flag in the table, to allow > the old, no longer needed value, to remain, but not show up in the combo > box. Unfortunately, this would prevent the decode action from > displaying the value. How do you handle that? Those two consecutive paragraphs do puzzle me. Obviously you give the solution in the first paragraph - access can enforce referential integrity. So why would you need hidden flags or mask unused values? > > One way of handling that I have used is to have the unused indicator and > sort the combo records so the unused are at the bottom of the list with > "NOT CURRENTLY USED" in the display as column 2. That makes the decode > work. And I add logic to produce an error if a user tries to select a > Not Currently used value for an empty combo box field. Why is the entry in the table in the first place? If every attempt to use a previously unused value raises an error that value is at best superfluous. And the description of "not _CURRENTLY_ used" is misleading since there seems no way to ever use it. > > Of course, smart users can get around all this by simply typing the new > 10 values of the combo box, over the existing 10 values, thereby > destroying the historical data. That doesn't make sense if your data model is correct. Your combo box shows just the description but is bound to the foreign key. Or at least it should. Then every time somebody wants to change an existing entry access should fire a "not_in_list" event. You can't just replace the description through a simple combo box. To make the design a bit more clear just consider the following example. Please forgive me for that silly example. It's just to show my point. We have two tables. Table 1 holds information for persons. Table 2 just lists the titles. Table 1 has the following fields: ID - autonumber, Primary Key txtName - text fktitle - long integer table 2 just holds ID - autonumber, Primary Key txtTitle - text Between table 1:fkTitle and table 2:ID is a 1:n relation and access is told to enforce referential integrity. Cascade Delete must not be checked! Table 2 holds these entries: 1, Ms 2, Mrs 3, Miss 4, Master 5, Madam 6, M'lady The combo box on the persons form is based on table 2 and bound to fktitle. Since Access is enforcing referential integrity a user can not enter another title(he can however leave it blank). When he tries to change one of the existing titles access treats it as a new one and fires the NotInList event. There you can change the existing one or add another title to table 2. However key to that functionality is that access has an established 1:n relation and referential integrity checked. With that in place no user can delete a used entry in table 2 as long as there are corresponding entries in table 1. Access prevents it and there is no way around! If it is unused the deletion will of course succeed. So it seems you are missing the part where you establish relations and set their properties. Hagen
Back to comp.databases.ms-access | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Managing changes to combo box contents when values are contained in a table BobAlston <bobalston9@yahoo.com> - 2014-03-12 11:39 -0500
Re: Managing changes to combo box contents when values are contained in a table "Ron Paii" <None@none.com> - 2014-03-12 12:44 -0500
Re: Managing changes to combo box contents when values are contained in a table BobAlston <bobalston9@yahoo.com> - 2014-03-12 16:58 -0500
Re: Managing changes to combo box contents when values are contained in a table Bob Quintal <rquintal@sPAmpatico.ca> - 2014-03-13 10:24 +0000
Re: Managing changes to combo box contents when values are contained in a table Neil <xxx@gmail.com> - 2014-03-12 16:16 -0500
Re: Managing changes to combo box contents when values are contained in a table Hagen Weidlich <durragon@web.de> - 2014-03-14 22:14 +0100
Re: Managing changes to combo box contents when values are contained in a table BobAlston <bobalston9@yahoo.com> - 2014-03-14 21:05 -0500
Re: Managing changes to combo box contents when values are contained in a table "Phil" <phil@stantonfamily.co.uk> - 2014-03-15 09:55 +0000
Re: Managing changes to combo box contents when values are contained in a table Hagen Weidlich <durragon@web.de> - 2014-03-15 17:14 +0100
csiph-web