The evaluations are done a couple of times per year at most and the procedure is automated so it hardly takes any time to generate it. The users have the option of tweaking the parameters so they can assign different weights to mileage, age, maintenance costs and so on. This was done because the people in charge of the equipment maintenance and management do not agree on what unit should be rated higher (or lower).imagine that! Now they can run their own evaluation that serve their own needs and everybody is happy. Since the one table approach duplicates some of the data, it does take additional disk space; however, when I can buy a 1TB drive for $60, storage is not an issue. Javier, Javier Valencia, PE 913-829-0888 Office 913-915-3137 Cell 913-649-2904 Fax <mailto:[email protected]> [email protected] _____
From: [email protected] [mailto:[email protected]] On Behalf Of William Stacy Sent: Friday, December 17, 2010 2:49 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: One table vs. two tables. To me it would depend on how often you do the evaluations. if only once a year, then it doesn't matter much. if every month, that could mean entering the header info as much as 700x12 times per year. what a waste of time! plus, i would think you'd have each piece of equip elsewhere in the database with such things as when purchased/cost/location/etc. all of those things plus it's id # should reside in the first table. On Thu, Dec 16, 2010 at 11:40 AM, Javier Valencia <[email protected]> wrote: 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 <mailto:[email protected]> [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#. -- William Stacy, O.D. Please visit my website by clicking on : http://www.folsomeye.net
