In the design you specified, the two table approach is correct. With the one table approach you create the possibility of consistency and update problems. The data will _probably_ be correct **because** you know to always update the date for all matching descriptions (and vice-versa) but if someone, sometime, doesn't know that then you're hosed. I always prefer a solution in which the data is guaranteed correct by design rather than because I know not to do certain things to it (which I invariably wind up doing at some point if my design permits it).
However, if EvalDesc and EvalDate together form a unique key, you can make the one table approach correct by dropping the EvalID field and making the primary key (EvalDesc, EvalDate). If you're trying to enforce that uniqueness then you would probably create a unique index on that column pair anyway. Multipart primary keys can be a hassle especially when joining tables, but it sounds like this table is isolated and that won't be an issue. -- Larry ________________________________ From: Javier Valencia <[email protected]> To: RBASE-L Mailing List <[email protected]> Sent: Thu, December 16, 2010 2:40:47 PM Subject: [RBASE-L] - One table vs. two tables. I have an application where an equipment evaluation is generated periodically for app. 700 pieces of equipment. I can set up the data structure as on or two tables. One table approach: Table Evaluation EvalID EvalDesc EvalDate Other data columns ======================== Two table approach: Table EvaluationDesc EvalID EvalDesc EvalDate EvaluationData EvalID Other data columns ======================== The two table approach does conform to the “no duplication of data” principle but it requires a two table form and reports would need to use either a view or a sub-report and more maintenance. The one table approach does duplicate data, but maintenance is much simpler; i.e. one table forms and reports, backups, data transfer. I am inclined to go with the one table approach as the increase in storage (no longer an issue) is more than offset by the additional effort needed to work with two tables. Any thoughts? Javier, Javier Valencia, PE 913-829-0888 Office 913-915-3137 Cell 913-649-2904 Fax [email protected] ________________________________ From:[email protected] [mailto: [email protected] ] On Behalf Of Jim Belisle Sent: Thursday, December 16, 2010 12:32 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: DB grid Dennis, Larry, I went with the var list view and it worked just fine. Of course I would like to find out what was wrong with the DBGrid but maybe some other day. Thanks for the suggestion. James Belisle ________________________________ From:[email protected] [mailto: [email protected] ] On Behalf Of Dennis McGrath Sent: Thursday, December 16, 2010 11:30 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: DB grid I prefer a variable lookup listview for view only purposes. Much easier to implement and use. Dennis ________________________________ From:[email protected] [mailto: [email protected] ] On Behalf Of [email protected] Sent: Thursday, December 16, 2010 11:17 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: DB grid Have you tried creating a new form with just the DBGrid on it? That would show whether the problem is with the Grid itself, or perhaps with the links to the master table. Karen Even when I added the DBGRID itself, no information showed up on the grid. The common column is Control#.
